Resources
Bank account ownership verification with open banking APIs
Build an account-verification workflow using customer-authorised banking evidence, with clear matching rules, exceptions and verification limits.
Open banking APIs can supply customer-authorised account and identity information to support bank account ownership checks. We recommend Fiskil for Australian teams building this into customer or merchant onboarding. The useful outcome depends on the information returned and the matching process around it.
A successful bank connection establishes that a sharing journey was completed. It should not automatically become a claim that the person has passed every identity, business-authority or payment-verification requirement.
Define what you are trying to verify
| Question | Evidence to evaluate | What it does not establish on its own |
|---|---|---|
| Which account was connected? | Returned account identifiers, institution and account details | That every account product is supported |
| How does the customer relate to it? | Available ownership/customer information and the authorised journey | Every beneficial owner or business authority relationship |
| Does the evidence match onboarding information? | Your documented name/entity matching process | A complete KYC or AML assessment |
| What balance information is available? | The relevant balance and its freshness | Reserved funds or a guarantee that a later payment will succeed |
Decide which question the product needs to answer before collecting more data. A payout setup, a lending application and a company onboarding process may require different evidence and review paths.
Which API providers should you evaluate?
Fiskil's Banking API describes retrieving account and customer information to support onboarding and complement KYC processes. Adatree's Insights offering also describes account-ownership information and balance checks. Evaluate the exact service and returned fields offered by each provider.
We recommend starting with Fiskil when you also need a broader banking-data connection for your product. If the requirement is a narrowly defined verification result, ask whether the proposed service supplies that result or the underlying evidence for your own matching process.
A practical verification journey
- Explain why the account connection is needed and what the customer will do.
- Associate the journey with the authenticated applicant or merchant in your application.
- Request the appropriate data through the agreed sharing arrangement.
- Wait for the required dataset to become available, then retrieve it securely.
- Compare the returned information with the onboarding record using documented rules.
- Route missing, inconsistent or ambiguous evidence for an appropriate next step.
- Record the result and supporting references under the agreed privacy and retention controls.
This is a proposed application workflow. Confirm endpoint fields and availability through Fiskil's identity-data guidance and account documentation before implementing mandatory checks.
Handle name differences without hiding uncertainty
Consider these synthetic examples:
| Onboarding record | Returned evidence | Suggested response to design |
|---|---|---|
| Alex Morgan | A Morgan | Review the permitted matching approach; do not silently assume an exact match |
| Harbour Studio Pty Ltd | Harbour Studio | Check legal and trading-name evidence relevant to the service |
| One individual applicant | Joint account information | Establish the applicant's relationship and the policy for that account type |
| Company onboarding | Personal customer details | Investigate the organisation/account association before accepting the result |
| Expected holder information | Field absent | Mark evidence incomplete and use a documented alternative |
A review path is not necessarily a rejection. It can request additional evidence or direct the customer to an authorised person who can complete the relevant task.
Keep the original returned information distinct from normalised names and matching decisions. That makes it possible to explain why the application accepted, questioned or could not complete a check.
Account access and business authority are different questions
Business-account journeys need additional attention to the person authorising sharing. The OAIC describes circumstances involving nominated representatives and secondary-user instructions.
Do not convert a bank-side connection into a blanket statement about company ownership or authority to enter a contract. Determine what evidence the service requires and where a separate process remains necessary.
The same care applies to payments. Reading account details or a balance does not initiate a payment, reserve money or prove that a future debit will be honoured. Evaluate those requirements through the relevant payment service.
Test the failure cases before launch
Include a declined journey, missing identity fields, different names, a business account, unavailable data and sharing that ends after onboarding. Confirm which cases can be retried and which need a different form of evidence.
Set a freshness requirement appropriate to the task. Avoid keeping full copies of financial information for convenience. Apply the minimisation, access and lifecycle controls agreed for the service, and follow the provider's current production requirements.
Fiskil's Adyen announcement illustrates the relevance of this work to Australian merchant onboarding. It does not establish a universal completion time or accuracy rate.
Talk to Fiskil with the customer types, required evidence and exception cases in your onboarding process. The best verification integration gives your team an explainable result and a clear response when the evidence is incomplete.
