Bank Account Verification
Bank Account Verification for Merchants: Why Account Ownership Matters Before Settlement A bank account can be perfectly real, correctly formatted, open at a legitimate bank, and still fail merchant onboarding. That sounds contradictory only if bank account verification is treate
Bank Account Verification for Merchants: Why Account Ownership Matters Before Settlement
A bank account can be perfectly real, correctly formatted, open at a legitimate bank, and still fail merchant onboarding.
That sounds contradictory only if bank account verification is treated as a technical exercise.
For a payment provider evaluating a merchant settlement account, the more important question is often relational:
Who owns this account, and why should money belonging to the onboarded merchant be settled there?
Current provider documentation makes that distinction visible. Checkout.com asks onboarding merchants for both bank-account details and the account owner name, then uses bank evidence to match those details against information supplied in the application. Adyen separately identifies failures for invalid bank numbers, missing account-owner names, account numbers that do not match bank evidence, and bank-account owner names that do not match the verified legal name.
So the core principle is:
Bank-account verification is primarily a relationship check between the settlement destination and the onboarded merchant—not merely validation of account-number syntax.
That distinction becomes especially important for groups, marketplaces, international businesses and merchants whose treasury structures involve entities other than the operating company.
What does merchant bank account verification actually establish?
Depending on the provider and arrangement, merchant bank account verification can involve several separate questions:
Does the account information appear valid?
Does the account exist or otherwise pass the provider's applicable banking checks?
Who is the account holder?
Does that account holder correspond to the legal entity being onboarded?
If it does not, what is the relationship between the two entities?
Is that relationship acceptable for settlement under the provider's rules?
Does the account's country, currency or other configuration meet the relevant settlement requirements?
Has sufficient evidence been supplied to resolve any exception?
These are related checks, but they are not interchangeable.
Adyen's current verification error taxonomy is particularly instructive. It has distinct bank-account errors for an invalid routing number, an invalid account number, a bank document missing the account owner's name, a bank-account number differing from the documentary evidence, and an account-owner name differing from the verified legal name. The separate errors demonstrate why technical bank-detail validation and bank-ownership verification are different problems.
Valid account versus verified ownership
Suppose a merchant enters:
IBAN: technically valid
Bank: legitimate institution
Currency: supported in the proposed setup
Account status: active
That can answer useful technical questions.
It does not necessarily establish:
Account holder: Example Payments Ltd
A separate ownership or documentary check may still be needed.
Worldpay's current Beneficiary Account Verifications API illustrates this distinction in another context. Its bank-verification request contains both bank details and an account-holder or company name, and the service can return an account-details match result. The stated purpose is to help ensure that a payout is going to the intended account.
Stripe's Financial Connections Ownership Match capability makes the separation similarly explicit: it compares bank-account ownership data with supplied owner information rather than treating connection to a bank account as proof that the relevant person or entity owns it. That product is currently a private-preview Stripe capability and should not be interpreted as a universal merchant-onboarding process.
The broader lesson is provider-neutral:
Account details identify a destination. Ownership verification establishes the relationship to that destination.
The operational mismatch: Merchant Ltd versus Holdings BV
Consider a hypothetical merchant group.
The entity applying to process payments is:
Example Payments Ltd
The proposed settlement account belongs to:
Example Holdings BV
Nothing in that fact pattern by itself proves misconduct.
Example Holdings BV might be:
the merchant's parent;
a group treasury company;
a centralized cash-management entity;
another operating subsidiary; or
an account holder participating in some other legitimate group arrangement.
But the evidence has introduced a relationship that must now be understood.
The provider may need to determine:
Example Payments Ltd
→ is entitled to settlement
→ settlement is proposed to Example Holdings BV
→ what connects the companies?
→ is the proposed arrangement permitted?
Checkout.com's current settlement-account process provides a concrete provider-specific example. When a bank-account holder is a different entity from the entity for which a bank-account change is requested, Checkout.com states that it asks for a justification. Its onboarding documentation also says additional information may be required when settlement is requested to a third-party bank account.
That does not mean every PSP prohibits or permits group settlement in the same circumstances.
It means the mismatch itself creates an additional verification question.
Why the merchant/entity relationship matters
Merchant onboarding identifies a particular legal entity.
That entity can be associated with information such as:
legal name;
registration details;
business activity;
ownership and control;
authorized representatives; and
proposed settlement arrangements.
Bank verification then needs to make sense in that context.
Checkout.com's current bank-verification instructions explicitly state that it uses the submitted bank statement to match bank information against details supplied in the application. Adyen's current platform verification errors likewise distinguish situations where the account-owner name on a bank document does not match the verified legal name.
This relationship is why business bank account verification sits naturally alongside KYB.
KYB establishes which business is being onboarded.
Bank-account verification asks whether the proposed financial destination belongs to—or can appropriately be connected with—that business.
For the broader legal-entity verification process, link to KYB Explained.
Technical validation versus compliance verification
A useful way to diagnose bank verification is to split it into two layers.
Layer 1 — Technical bank-detail checks
Depending on the provider and rail, systems may check information such as:
account number;
routing or branch code;
IBAN;
bank identifier;
country;
currency; or
other required banking fields.
These checks help determine whether the submitted banking information is structurally or operationally usable.
Layer 2 — Relationship and compliance checks
The provider may separately need to establish:
account-holder identity;
correspondence between the holder and merchant;
evidence of account ownership;
whether another entity owns the account;
whether a third-party arrangement is acceptable; and
whether geography or provider policy creates additional conditions.
Adyen's verification codes show these layers very clearly. It separately recognizes invalid routing numbers and account numbers, owner-name mismatches, country mismatches, currency mismatches, and bank-document deficiencies.
A merchant that fixes an IBAN typo has resolved a technical issue.
It has not necessarily resolved an ownership mismatch.
Proof of bank account: what can the evidence establish?
Providers use different verification methods, so there is no universal document list.
Where documentary proof is required, a provider may ask for evidence containing some combination of:
account-holder name;
bank name;
bank-account number or IBAN;
routing, sort, branch or bank code;
account-holder address;
currency information; or
other identifiers relevant to the applicable banking system.
Checkout.com's current onboarding process, for example, requests account-owner information, bank information, bank-account details and a bank statement, and specifies fields that its bank evidence should display.
Adyen's bank-account verification errors show what can happen when evidence lacks the required data: its current checks include specific errors when a bank document is missing the account number or account-owner name, when the account number on the evidence differs from the submitted number, or when the document type or quality is not accepted.
The purpose of proof of bank account is therefore not simply to show that the merchant possesses a PDF from a bank.
It is to establish the particular facts the provider needs to compare.
Three evidence layers
Merchants can think about bank verification through an evidence hierarchy.
Merchant-declared banking information
This is what the merchant enters into the application or settlement setup.
It might include:
Legal entity: Example Payments Ltd
Account holder: Example Payments Ltd
IBAN: …
Bank: …
Country: …
Currency: …
This is a claim.
Documentary evidence
Bank-issued evidence may help establish what the bank records show.
For example:
Account owner on bank evidence: Example Payments Ltd
Account identifier: matches application
Bank: matches application
The document supports the claim.
Independent or electronic verification
Where available and used by the provider, electronic banking or account-verification systems may independently verify bank or ownership information.
Stripe's Ownership Match technology, Adyen's bank-account verification checks and Worldpay's beneficiary-verification service all illustrate different provider approaches to electronic bank or ownership verification. They are different products serving different use cases and should not be treated as a single industry-standard process.
The important point is:
information supplied
→ evidence compared
→ discrepancies resolved
→ verification outcome
Submitting bank information is not the same thing as having the settlement account verified.
Legal name versus bank display name
Names frequently create avoidable friction.
The onboarded merchant might be:
Example International Payments Limited
while the bank interface displays:
Example Intl Payments Ltd
A difference does not automatically prove that the account belongs to somebody else.
But neither should the merchant assume that the provider will infer the relationship.
Possible explanations can include:
abbreviations;
truncation caused by bank-system field limits;
historical names;
transliteration;
trading-name use; or
another naming convention.
The relevant question is whether the provider can establish that both names identify the same legal relationship.
Adyen's current bank verification specifically identifies an account-owner-name mismatch against the verified legal name as a verification problem requiring remediation. Checkout.com similarly requests the account-owner name as part of bank verification and matches the bank evidence to application information.
The merchant response should therefore reconcile the discrepancy rather than simply resubmit the unchanged account details.
A trading name does not automatically answer the ownership question
A merchant may be commercially known by a brand that differs from its registered entity.
For example:
Legal entity: Example Payments Ltd
Trading name: PayExample
Bank account holder: Example Payments Ltd
That is different from:
Legal entity: Example Payments Ltd
Bank account holder: Example Holdings BV
The first can be a naming issue.
The second is an entity relationship.
Both may need explanation, but they are different verification questions.
When diagnosing a mismatch, merchants should identify whether they are dealing with:
same entity, different representation
or:
different legal entities
That distinction determines what evidence or explanation is likely to be relevant.
Parent-company and group accounts
Group structures make settlement account verification more complicated because the company selling to the customer and the company holding the bank account may not be identical.
That can occur in legitimate treasury arrangements.
But legitimacy does not mean automatic provider acceptance.
Checkout.com's current documentation explicitly says it may request additional information where funds are to be settled to a third-party account, and its bank-account-change process asks for justification when the bank holder is a different entity.
The merchant should therefore be ready to establish:
Which entity is onboarded?
Which entity owns the bank account?
What is the legal or corporate relationship?
Why is that entity receiving settlement?
What evidence supports the relationship?
Does the payment provider permit the structure?
The answer to Question 6 is provider-specific.
Do not assume that another PSP's acceptance of the same group treasury arrangement proves that the current PSP must accept it.
Third-party accounts
A third-party settlement account raises the same relationship issue more sharply.
The bank account might belong to:
another group company;
a treasury company;
a payment intermediary;
a commercial partner; or
another third party.
A technically functional bank account does not explain why that party should receive the merchant's settlement.
Checkout.com's current onboarding guidance says additional information may be required where a merchant wants to settle funds into a third party's bank account irrespective of jurisdiction.
That is a Checkout.com policy example, not a universal prohibition or permission.
A merchant proposing such a structure should therefore disclose it accurately and ask what relationship evidence and settlement conditions apply.
Account geography can introduce another check
Bank-account country and merchant country are not necessarily the same thing.
Whether that is allowed depends on the provider, settlement architecture, currency, acquiring arrangement and other relevant requirements.
Checkout.com, for example, states that it may seek additional information if settlement is requested in a country different from the legal entity's primary place of business. Adyen's current verification errors also include a bank-account-country mismatch against supplied bank evidence in its platform verification framework.
The correct merchant conclusion is not:
“Settlement accounts must always be domestic.”
Nor is it:
“Any foreign account works if the IBAN is valid.”
The question of whether a merchant needs a local entity or bank account belongs in the Entity & Settlement topic cluster.
This article owns the narrower question:
Once a settlement account is proposed, can its ownership and relationship to the merchant be verified and is the configuration acceptable to the provider?
Bank-account ownership does not establish source of funds
Another distinction is important.
Proving:
Example Payments Ltd owns account X
does not necessarily establish:
where every amount moving through account X originated.
Those are different verification objectives.
Bank ownership verification concerns the relationship between an account and the relevant person or entity.
Source of funds concerns the origin of money relevant to a particular business relationship, transaction or other applicable context.
If a provider separately asks where certain money came from, a bank statement proving account ownership does not automatically answer that question.
That adjacent issue belongs in Source of Funds Explained.
Common bank-verification failures
The most useful way to troubleshoot payment provider bank verification is to identify exactly which relationship failed.
Invalid account details
The account number, routing number or another banking field does not pass the applicable check.
Problem: technical data.
Merchant response: confirm the original bank details rather than repeatedly uploading ownership evidence.
Adyen's current bank-check errors distinguish invalid routing and account numbers from documentary ownership errors.
Bank evidence belongs to the correct account but lacks the holder name
Problem: evidence cannot establish ownership.
Merchant response: provide the provider-accepted evidence containing the required ownership information.
Both Checkout.com and Adyen identify account-owner information as part of their current bank-verification processes.
Account number differs between application and evidence
Problem: the declared destination and documentary destination do not reconcile.
Merchant response: determine which value is correct before submitting again.
Adyen explicitly identifies this mismatch in its current verification errors.
Bank account is owned by another entity
Problem: the relationship between merchant and settlement destination remains unresolved.
Merchant response: disclose the relationship and provide the explanation or evidence the provider requests.
Checkout.com's current process specifically contemplates further review or justification in third-party or different-entity settlement situations.
Name differs from the verified merchant name
Problem: it is unclear whether this is a naming variation or a different account holder.
Merchant response: identify which one it is and reconcile it.
Adyen treats an account-owner name that differs from the verified legal name as a distinct bank-account verification error.
Document quality prevents verification
Problem: evidence exists but cannot be reliably checked.
Merchant response: replace the defective evidence rather than sending the same unreadable document again.
Checkout.com currently rejects bank evidence that is blurry, cropped, altered, outdated under its specified policy, or missing required information. Adyen similarly maintains specific errors for low-quality or unsupported bank documents.
Country or currency information does not reconcile
Problem: settlement configuration and bank evidence differ.
Merchant response: verify what the provider expects for the particular account, currency and jurisdiction.
Adyen's current error taxonomy includes distinct country and currency mismatches in bank-account checks.
The Bank Account Verification Flow
A merchant can reduce avoidable rework by treating bank verification as a sequence of relationships.
Step 1 — Identify the merchant entity
Start with the exact legal entity being onboarded.
Merchant: Example Payments Ltd
Do not start with the bank account.
Step 2 — Identify the proposed settlement account
Record the account precisely:
account holder;
bank;
country;
currency;
account identifier; and
other required banking fields.
Step 3 — Establish that the account details are usable
Resolve technical problems such as incorrect or invalid bank-account information.
Do not confuse successful technical validation with completed ownership verification.
Step 4 — Establish the account holder
Determine whose name or entity appears as the legal account holder.
Step 5 — Compare holder with merchant
Ask:
Merchant entity = account holder?
If yes, proceed to the remaining provider checks.
If no, do not hide the discrepancy.
Move to Step 6.
Step 6 — Establish the third-party or group relationship
Document:
Merchant entity
→ relationship
→ account-holder entity
For example:
Example Payments Ltd
→ wholly owned subsidiary of
Example Holdings BV
The existence of the relationship does not itself guarantee that the provider will permit that settlement setup.
Step 7 — Check geography and provider policy
Determine whether the proposed:
bank country;
settlement currency;
account-holder structure;
group arrangement; and
settlement destination
fit the provider's current requirements.
Do not copy rules from another PSP.
Step 8 — Resolve the exception
If there is a mismatch, identify exactly what remains unresolved:
ownership;
entity relationship;
name;
geography;
currency;
bank evidence; or
provider eligibility.
Submit evidence for that question.
Step 9 — Confirm the approved settlement destination
Bank verification is complete only when the relevant provider has actually accepted or verified the destination according to its process.
Do not interpret “bank account added” as necessarily equivalent to “bank account verified.”
C. ORIGINAL ARTICLE ASSET — BANK ACCOUNT VERIFICATION FLOW
Stage
Verification question
Merchant evidence/output
Common failure
Merchant entity
Which legal entity is being onboarded?
Verified legal entity details
Trading name used instead of legal entity
Settlement account
Where should settlement go?
Bank details and proposed currency/country
Incorrect account selected
Account validity
Are the banking details technically usable?
Account/routing/IBAN data
Invalid or mistyped details
Account holder
Who owns the bank account?
Bank ownership evidence or accepted electronic verification
Owner absent from evidence
Entity match
Does the holder match the merchant?
Reconciled legal names
Name/entity mismatch
Relationship
If different, why is another entity receiving funds?
Group/third-party relationship evidence where requested
Relationship unexplained
Geography/policy
Is the configuration permitted?
Provider-specific eligibility confirmation
Unsupported or further-review configuration
Exception resolution
What mismatch remains?
Corrected or supplementary evidence
Same irrelevant evidence resubmitted
Settlement approval
Has the provider accepted the destination?
Verified/approved provider status
“Submitted” mistaken for “verified”
Bank Relationship Diagnostic
When verification fails, ask these questions in order:
Does the bank-account number match the evidence?
→ No: correct the account details.
Does the evidence identify the account owner?
→ No: supply accepted ownership evidence.
Does the account-owner name correspond to the onboarded entity?
→ Yes: resolve any remaining bank/provider checks.
→ No: continue.
Is this the same entity under a legitimate naming variation?
→ Yes: document the naming relationship.
Is this genuinely another legal entity?
→ Yes: explain the corporate/third-party relationship.
Does the provider allow that settlement relationship?
→ Unknown: obtain provider-specific confirmation.
→ No: change the settlement structure rather than attempting to disguise the relationship.
→ Yes, subject to evidence: provide the requested relationship evidence.
This diagnostic should be presented as a decision tool, not as a universal PSP policy.
How merchants can prepare bank evidence before onboarding
The merchant-controlled objective is consistency.
Before submitting the proposed settlement account, reconcile:
Merchant
exact legal entity name;
incorporation jurisdiction;
relevant trading name, if any; and
entity selected in the PSP application.
Bank account
account-holder name;
bank;
country;
currency;
account number or IBAN;
routing or branch information where relevant.
Evidence
does it show the account being submitted?
does it identify the holder?
does the holder name reconcile with the merchant?
is it complete and readable?
does it satisfy the provider's current document rules?
Relationship
If the account holder differs:
identify the second entity;
describe the group or third-party relationship accurately;
prepare evidence of that relationship where relevant; and
ask the provider whether the structure is eligible.
Do this before repeatedly uploading bank documents.
How to respond to a bank-account mismatch
A useful response identifies the discrepancy directly.
For example:
Onboarded entity: Example Payments Ltd
Proposed bank-account holder: Example Holdings BV
Relationship: Example Holdings BV is the parent company of Example Payments Ltd
Reason for proposed settlement structure: [accurate commercial explanation]
Supporting relationship evidence: [provider-requested evidence]
Question for provider: Please confirm whether this group settlement structure is eligible and what additional verification evidence is required.
That is more useful than:
“The account is valid. Please approve it.”
The account's validity was never the complete question.
Do not modify evidence to manufacture a match
If the legal entity name and bank-account holder genuinely differ, do not try to make them appear identical.
Do not:
edit bank evidence;
alter an account-holder name;
omit the actual account owner;
substitute a group company without disclosure;
manipulate screenshots;
misstate the corporate relationship; or
route settlement through another entity merely to avoid verification.
A legitimate mismatch should be explained and verified, not concealed.
Changing the bank account later can trigger verification again
Bank-account verification is not necessarily a one-time concept tied only to initial onboarding.
A later change to the settlement destination can require the new account and its relationship to the merchant to be checked.
Checkout.com's current process for adding or changing settlement bank accounts requires verification information about the entity and new account and specifically addresses situations where the new holder is a different entity.
Adyen's platform verification architecture likewise treats bank-account information as a distinct verification subject, with specific remediation states where submitted details or evidence cannot be verified.
Merchants with treasury changes, reorganizations or new bank relationships should therefore treat a settlement-account update as a controlled operational change rather than simply replacing an IBAN in a settings screen.
Operational metrics for recurring bank-verification friction
If bank verification repeatedly slows merchant activation, useful internal measures can include:
Bank-verification discrepancy rate
Applications with at least one bank-data or ownership discrepancy
÷
Relevant applications requiring bank verification
Bank-evidence resubmission rate
Bank-verification requests requiring replacement or corrected evidence
÷
Relevant bank-verification requests
Entity-mismatch rate
Cases where proposed bank-account holder differs from the onboarded entity
÷
Relevant bank-verification cases
Time to bank exception resolution
Time from a documented bank-verification exception
to
provider confirmation that the issue is resolved
Do not compare these measures externally unless the underlying definitions and populations are genuinely comparable.
The objective is to determine whether recurring delay comes from:
data entry;
evidence quality;
entity mismatch;
treasury structure;
provider clarification time; or
another identifiable dependency.
Frequently asked questions
What is bank account verification for a merchant?
It is the process of establishing relevant facts about the account proposed for merchant settlement or payout. Depending on the provider, those facts can include account details, account ownership, correspondence between the holder and merchant entity, documentary evidence and settlement eligibility.
Checkout.com's current onboarding process, for example, collects the account-owner name alongside banking details and uses bank evidence to match the supplied account information.
Is a valid IBAN enough for merchant bank verification?
Not necessarily.
A technically valid IBAN can identify a plausible bank account without establishing that the onboarded merchant owns it. Adyen's verification framework separately distinguishes invalid bank details from account-owner-name mismatches and other ownership-evidence failures.
Why does a payment provider need the bank account holder's name?
The account-holder name can help establish who owns the proposed settlement destination and whether it corresponds to the merchant or another relevant entity.
Checkout.com explicitly requests an account-owner name during its current bank-verification process, while Adyen identifies a missing or mismatching owner name as a separate bank-verification failure.
Can settlement go to a parent company's bank account?
Possibly in some arrangements, but there is no provider-neutral rule that makes a parent account automatically acceptable.
Checkout.com, for example, states that it seeks justification where the bank-account holder is a different entity during its bank-account-change process and may request additional information for third-party settlement arrangements. Other providers can use different requirements.
What if the company name on the bank statement is slightly different?
First determine whether it is genuinely the same legal entity under a different representation or a different legal entity.
A naming variation may be explainable. A separate company creates an entity-relationship question. Providers may require the discrepancy to be resolved before accepting the account; Adyen, for example, expressly treats an account-owner name that does not match the verified legal name as a bank-account verification error.
Does the bank account need to be in the merchant's country of incorporation?
Do not assume a universal rule.
Requirements depend on the provider, settlement arrangement, geography, currency and other applicable conditions. Checkout.com states in its own current onboarding process that additional information may be required when settlement is requested in a country different from the merchant legal entity's primary place of business.
Whether a merchant needs a local account in a specific market belongs in the separate Entity & Settlement analysis.
Is a bank statement always required?
No universal statement should be made.
Verification methods and acceptable evidence vary. Checkout.com currently requires specified bank evidence in many of its onboarding scenarios while noting an alternative path for certain UK bank accounts; other providers can use documentary or electronic methods according to their products and jurisdictions.
Does bank ownership verification prove source of funds?
No.
They answer different questions. Bank-account ownership asks who owns or is connected with the account. Source-of-funds review asks where relevant money originated. If source-of-funds evidence is required in a particular onboarding context, proving account ownership alone does not necessarily answer it.
Final takeaway
A settlement account is not simply a string of bank coordinates.
It is a destination for money generated by a specific merchant relationship.
That is why the correct bank account verification merchant workflow is:
merchant entity
→ proposed settlement account
→ account details checked
→ account holder established
→ merchant/holder relationship reconciled
→ group or third-party relationship explained where relevant
→ geography and provider policy checked
→ exceptions resolved
→ settlement destination verified
The most important question is not:
“Does this IBAN work?”
It is:
“Can we establish why this account is the correct destination for settlement belonging to this merchant?”
If the account belongs to the onboarded entity, make that relationship easy to verify.
If it belongs to another entity, make the relationship explicit.
A legitimate bank account does not become a verified merchant settlement account merely because money can technically be sent to it.
Disclaimer: This article provides general information and does not constitute legal, regulatory, compliance, tax, accounting, or financial advice. KYC and KYB requirements vary by jurisdiction, regulated activity, provider, financial institution, merchant structure, and risk profile. Merchants should verify current requirements with qualified advisers, relevant authorities, and their payment providers or acquirers.
🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂
ARTICLE END
The draft below follows the brief’s assigned territory: settlement-account ownership verification, not the separate question of whether a merchant needs a local bank account.
Bank Account Verification for Merchants: Why Account Ownership Matters Before Settlement
A. Brief interpretation — editorial, not part of the article
Article-owned question: Can the merchant demonstrate that the proposed settlement account belongs to, or is legitimately connected with, the onboarded merchant under the applicable provider requirements?
Verification subject: The proposed bank account, its account holder, and the relationship between that holder and the legal entity being onboarded.
Verification objective: Establish that the bank account exists, identify who owns it, reconcile that ownership with the verified merchant entity, and determine whether the account is eligible to receive settlement under the relevant provider and acquiring arrangement.
Key distinction: A technically valid account number or IBAN does not establish who owns the account.
Editorial position: A valid bank account is not automatically the correct merchant settlement account.
Unique evidence anchor: If Example Payments Ltd is the merchant but the bank evidence identifies Example Holdings BV, the bank account may be genuine. The unresolved question is why funds owed to one entity are being directed to another.
Final merchant decision: Can the merchant prove the relationship between the onboarded entity and the proposed settlement destination clearly enough to satisfy the applicable provider requirements?
B. COMPLETE PUBLICATION-READY ARTICLE
D. SEO PACKAGE — not part of the article
H1: Bank Account Verification for Merchants: Why Account Ownership Matters Before Settlement
Meta description: Learn how merchant bank account verification works, why account ownership matters for settlement, what name and entity mismatches mean, and what evidence PSPs may request.
URL slug: /bank-account-verification-merchants
Secondary keywords:
bank account verification KYB
merchant bank account verification
payment provider bank verification
business bank account verification
settlement account verification
bank ownership verification
proof of bank account
Related entities:
Settlement account
Merchant
Legal entity
Bank account holder
PSP
Acquirer
KYB
Bank statement
IBAN
SWIFT/BIC
Routing number
Treasury
Parent company
Third-party account
Source of funds
Article excerpt:
A technically valid bank account is not automatically a verified merchant settlement account. Payment providers may need to establish who owns the account, whether that holder corresponds to the onboarded merchant, and whether any group, third-party or cross-border settlement relationship is permitted.
Suggested internal links
KYB Explained
Placement: after the section explaining the relationship between the verified legal entity and the account holder. KYB should own the broader legal-entity verification process.
Entity & Settlement cluster
Placement: in the account-geography section. That cluster should own whether local entities or local bank accounts are required, settlement architecture, and cross-border fund design.
Source of Funds Explained
Placement: after the distinction between account ownership and the origin of funds.
Do not expand this article into those adjacent subjects solely to capture additional keywords.
Suggested structured data
Primary: Article
Potential supplementary structured data:
FAQPage for the article's FAQ section where current search-engine policy and publisher practice support it.
Person for the genuine author or technical reviewer once selected.
dateModified reflecting the last meaningful factual/compliance review.
Supporting visual
Bank Account Verification Flow
Design a horizontal or vertical process:
Merchant entity
↓
Proposed settlement account
↓
Account details technically valid?
↓
Account holder established
↓
Holder matches merchant?
Branch:
YES
→ Geography/provider checks
→ Remaining exceptions resolved
→ Verified settlement destination
NO
→ Same entity under naming variation?
→ Different group/third-party entity?
→ Relationship evidence
→ Provider eligibility decision
→ Exception resolved
→ Verified settlement destination
Add a highlighted callout:
Valid account ≠ verified ownership
And a second:
Different holder ≠ automatically invalid; relationship must be established and permitted.
Recommended image alt text
“Bank Account Verification Flow showing the merchant entity, proposed settlement account, account validity, account-holder verification, merchant name matching, group or third-party relationship checks, geography and provider policy, and settlement approval.”
E. SOURCE AND VERIFICATION PLAN — not part of the article
Authoritative sources used
Checkout.com — Verify your bank accounts
Current first-party onboarding documentation. It states that Checkout.com requests information including account-owner name, owner address, bank name, bank address and relevant account identifiers and uses bank statements to match banking data supplied in the application. It also identifies situations in which additional information may be required, including settlement in another country and settlement to a third-party bank account.
Editorial use: Primary support for the article's settlement-account relationship thesis.
Do not generalize: Checkout.com's acceptable evidence, recency requirements or exceptions into universal PSP requirements.
Checkout.com — Add or update your bank account and settlement schedule details
Current first-party settlement documentation. It states that the entity affected by the change and account-holder name must be identified and that Checkout.com requests justification where the holder is another entity.
Editorial use: Primary support for the Example Payments Ltd / Example Holdings BV relationship problem.
Adyen — Platform KYC verification suberror codes
Current first-party technical documentation that separately identifies:
invalid routing/account details;
missing account-holder name;
account-number/document mismatch;
account-owner-name/legal-name mismatch;
bank-country mismatch;
currency mismatch;
unsupported or poor-quality bank evidence; and
other bank-verification failures.
Editorial use: Strong evidence for the distinction between technical validation, documentary verification and legal-entity matching.
Do not generalize: Individual error criteria or documentary rules beyond the cited Adyen product context.
Adyen — Open Banking account verification
First-party documentation describing an account-verification report used to verify bank-account ownership and retrieve identity and account details.
Editorial use: Evidence that account ownership can be verified electronically and need not always be conceptualized solely as document upload.
Worldpay — Beneficiary Account Verifications API
Current first-party documentation for a beneficiary-verification product intended to check bank details before payout. The request includes account-holder/company information and can produce name/detail matching outcomes.
Editorial use: Supporting evidence for the distinction between bank routing data and the intended beneficiary relationship.
Scope warning: This is a beneficiary verification service, not evidence of a universal Worldpay merchant-onboarding workflow.
Stripe — Financial Connections Ownership Match
Current Stripe documentation for an ownership-matching capability that compares bank-account ownership data against supplied owner information. The feature is currently described as private preview.
Editorial use: Supporting evidence that ownership matching is a distinct verification operation rather than an automatic consequence of collecting bank details.
Scope warning: Do not describe this feature as generally available or as Stripe's universal merchant settlement verification process.
Claims requiring primary-source verification before publication
Recheck immediately before publishing any statement concerning:
provider-accepted proof-of-bank-account documents;
document age requirements;
electronic bank verification availability;
third-party settlement-account eligibility;
group treasury account eligibility;
acceptable bank-account countries;
supported settlement currencies;
same-country or cross-border settlement restrictions;
name-match policies;
account-change procedures;
payout or settlement-account requirements;
bank-account verification APIs;
jurisdiction-specific legal restrictions.
Provider settlement rules can change.
Jurisdiction-specific checks
No universal legal rule requiring merchants to settle into an account in their incorporation country is asserted in this draft.
If country-specific versions of this article are created, verify:
legal and regulatory framework;
payment institution/acquirer obligations;
bank-account ownership requirements;
restrictions on third-party settlement;
safeguarding or settlement implications where relevant;
permitted account jurisdictions;
local banking identifiers;
electronic account-verification availability;
applicable privacy/data rules; and
any local requirements distinguishing corporate and personal accounts.
Do not extrapolate provider policy into legislation.
Provider-policy checks
Immediately before publication, confirm the current provider's:
bank ownership verification process;
evidence types;
accepted file standards;
account-holder-name rules;
naming mismatch process;
bank-country requirements;
currency requirements;
third-party/group account treatment;
account-change workflow;
electronic verification capabilities; and
exception/escalation process.
Each provider example should remain explicitly provider-specific.
requires settlement accounts to be held by the merchant legal entity;
permits or prohibits parent/group settlement accounts;
permits third-party settlement;
supports particular bank-account jurisdictions;
verifies IBANs or accounts automatically;
provides account-owner matching;
uses particular bank documents;
requires documents within a particular age;
supports particular settlement currencies;
accepts particular naming discrepancies;
permits specific treasury arrangements;
completes bank verification within a defined timeline; or
can override bank, acquirer or regulatory settlement requirements.
F. HUMAN REVIEW RECOMMENDATION — not part of the article
Recommended author profile:
Payments writer or merchant-onboarding specialist familiar with KYB, settlement architecture and treasury operations.
Primary compliance reviewer:
KYC/KYB or merchant-compliance specialist who can confirm the distinction between verifying a legal entity and verifying its proposed settlement destination.
Banking/settlement reviewer:
Payments operations, treasury or banking-onboarding specialist with practical experience in bank-account ownership checks, group accounts and settlement-account changes.
Regional reviewer:
A regional payments or compliance specialist should review any version that makes country-specific claims about bank geography, local accounts or settlement eligibility.
Legal review:
Payments counsel should review any statement describing a settlement-account relationship as legally required or prohibited in a named jurisdiction.
Operational contribution:
A merchant-onboarding or treasury specialist could provide an attributed, real example of a recurring mismatch such as:
parent account versus operating company;
abbreviated bank account name;
newly changed settlement account; or
cross-border account configuration.
Suggested last-reviewed practice:
Display a last-reviewed date and recheck provider bank-verification documentation periodically and whenever settlement policy materially changes.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗