What Does a Bank Account Verification Return? (South Africa 2026)

A bank account verification in South Africa is only useful if you understand the response. Running the check is fast; interpreting the result is where most teams get stuck. A "partial match" is not a fraud signal by itself. An accountFound: "No" is sometimes a typo, sometimes a closed account, and sometimes an attempted fraud. The difference is in the fields.

This guide walks through every field VerifyNow returns in a bank account verification, with realistic example values, typical failure modes, and decision rules you can drop straight into your finance or onboarding workflow. It is written for accounts payable teams, payroll administrators, compliance officers and fraud analysts working in ABSA, FNB, Standard Bank, Nedbank, Capitec, Investec, African Bank, TymeBank, Bidvest Bank and the rest of the South African banking ecosystem.

Quick recap — what a bank account verification is

Bank account verification authenticates a South African bank account in real time against the records held by the relevant financial institution. You submit an account number, branch code, identity number and name; VerifyNow returns a structured response describing whether the account exists, whether it's open, whether the account holder matches the identity you supplied, and whether the account accepts credits and debits.

It takes a few seconds, costs 6 credits in production, and produces an auditable record aligned with FICA customer due diligence obligations and POPIA processing rules. For the full how-to, see our step-by-step guide or the bank account verification service page.

The full response — twelve fields

Every VerifyNow bank account verification returns the following twelve fields. We'll unpack each one below with an example value.

1. accountFound

What it tells you: Whether the account number + branch code combination exists at the specified bank.

Example values: "Yes" or "No".

Decision rule: "No" means either (a) a typo in the account number or branch code, or (b) the account has been closed and purged, or (c) the details supplied to you are fabricated. Always pause and confirm before resubmitting.

2. accountOpen

What it tells you: Whether the account is currently active at the bank.

Example values: "Yes" or "No".

Decision rule: An account that was found but is not open is a red flag for fraud — a criminal may have quoted the details of a closed account. Do not pay. Request a live proof of banking dated within 30 days.

3. acceptsCredits

What it tells you: Whether the account can receive incoming payments.

Example values: "Yes" or "No".

Decision rule: Some frozen or investigation-locked accounts do not accept credits. If this is "No", your payment will fail — verify on a different account before sending.

4. acceptsDebits

What it tells you: Whether the account can have debit orders drawn off it.

Example values: "Yes" or "No".

Decision rule: Relevant for subscription billing, debit-order collections (DebiCheck), and recurring loan repayments. A "No" here means debit orders will bounce — worth knowing before you start a subscription relationship.

5. lengthOpen

What it tells you: How long the account has been open with the bank.

Example values: "5 years 3 months", "2 months", "Less than 1 month".

Decision rule: Accounts less than 30 days old are statistically higher-risk for fraud. Combine with other signals — a brand-new Capitec account with a matching identity is normal; a brand-new account with a name mismatch is not.

6. identityMatch

What it tells you: Does the ID number you supplied match the ID number on record at the bank for this account holder?

Example values: "Yes" or "No".

Decision rule: This is the strongest single fraud signal in the whole response. If the bank is saying "the ID number you gave me does not match the ID number I have on file for this account", you are probably looking at third-party account details. Do not pay.

7. accountTypeMatch

What it tells you: Did you tell us Savings, Current, Transmission, Bond or SubscriptionShare — and does that match the bank's record?

Example values: "Yes" or "No".

Decision rule: A soft signal. A mismatch here often means the customer mis-labelled their own account type — common for Capitec GlobalOne and FNB Easy accounts. Combine with identityMatch and nameMatch before rejecting.

8. nameMatch

What it tells you: Does the first name + surname you supplied match the account holder's name on record?

Example values: "Yes", "No", or a partial match indicator.

Decision rule: A second strong signal alongside identityMatch. Common causes of "No" with a legitimate customer: nicknames (Thandi vs Thandiwe), initials vs full names (J Smith vs John Smith), maiden name not yet updated at the bank after marriage. Treat nameMatch: "No" with identityMatch: "Yes" as a review-and-confirm, not an auto-reject.

9. bankReference

What it tells you: The bank's own internal reference for this verification request.

Example value: "REF-2026-04-17-000583921".

Decision rule: Log this against your verification audit record. If a dispute arises later, this is the reference your bank will use to look up the transaction on their side.

10. bankStatusCode

What it tells you: The status code returned by the responding bank.

Example values: "0" (clean), various non-zero error codes.

Decision rule: "0" means the bank processed the request without error. Non-zero codes usually mean a technical issue (timeout, routing error) rather than fraud — re-run the verification. If non-zero codes persist for the same account, confirm the branch code is correct.

11. identity_and_account_verified

What it tells you: A single Boolean that is true only when accountFound, identityMatch and nameMatch all return "Yes".

Example values: true or false.

Decision rule: Use this as your default green-light gate. If identity_and_account_verified is true, the verification has passed the three most important checks. If false, drop into the detailed fields to decide whether to review or reject.

12. summary

What it tells you: A human-readable summary of the verification result.

Example values: "Identity, Bank Account and Name Verified" or "Verification Failed or Partial Match".

Decision rule: Great for customer-service agents and audit logs. Not a substitute for looking at the underlying fields.

The three common failure modes

Failure mode 1: accountFound: "No"

The account number + branch code combination does not exist.

• Most common cause: a typo (especially swapping 0 and O, or truncating a 10-digit account to 9 digits).
• Second most common: the account has been closed.
• Fraud signal: occasionally, fabricated details supplied on a fake invoice.

Action: Re-check the account number and branch code on a dated proof of banking. If still "No", request a fresh proof of banking from a verified email address of the counterparty.

Failure mode 2: identityMatch: "No"

The account exists but the ID number you supplied does not match the account holder.

• Most common cause: you have the right account number but wrong ID number (data entry error).
• Fraud signal: you have third-party account details quoted to you as if they belong to the person you're dealing with.

Action: Do not pay. Request the counterparty's ID number and proof of banking together. Re-run the verification.

Failure mode 3: nameMatch: "No" (but identityMatch: "Yes")

The ID number matches but the name doesn't.

• Most common cause: nicknames, initials, missing middle names, or an unchanged maiden name on the bank's records.
• Rarely a fraud signal on its own.

Action: Review and confirm with the counterparty. Document the reason for the partial match in your audit notes and proceed.

Interpreting bankStatusCode — a quick reference

• "0" — Success, no errors. The other fields can be trusted.
• Non-zero, transient — Bank timeout, communication error, or intermittent bank-side issue. Re-run the verification after a few minutes.
• Non-zero, persistent for the same account — Usually a data problem with the submitted details (branch code mismatch, account type not supported for verification at that bank). Verify inputs and try the bank's universal branch code.
• Non-zero, persistent across multiple accounts at the same bank — Contact support.

Individual vs Company verifications

VerifyNow supports both individuals and companies.

• Individual (type: "Individual"): pass a 13-digit SA ID number, first name and surname. All twelve fields are populated as above.
• Company (type: "Company"): pass a CIPC company registration number (or trust number), the registered entity name as surname, and set identityType to CompanyRegNumber or TrustNumber. The response shape is identical, but identityMatch is now "does the registration number match the account holder on file" and nameMatch is "does the registered name match".

Trading names will always fail nameMatch against the CIPC record — always verify with the registered name, not the brand name.

How identity_and_account_verified consolidates the signals

Rather than writing custom logic across accountFound, identityMatch and nameMatch, most teams key their pay/review/reject decision off identity_and_account_verified:

• true → green light. Proceed with payment.
• false → drop into the detailed fields. At minimum inspect accountFound, identityMatch, nameMatch, accountOpen and bankStatusCode before making a decision.

This keeps the happy path simple while still letting fraud analysts and finance leads interrogate the edge cases.

Using verification output for fraud prevention decisions

A practical decision matrix:

• Reject if accountFound: "No" after a clean re-run.
• Reject if nameMatch: "No" AND identityMatch: "No" — two independent mismatches.
• Review if only one of nameMatch or identityMatch is "No". Confirm with the counterparty through a trusted channel (phone number on file, not the number on the suspect invoice).
• Proceed with elevated monitoring if lengthOpen is less than 90 days and identity_and_account_verified is true — especially for high-value payments.
• Proceed if identity_and_account_verified is true and lengthOpen is greater than 12 months.

Tune these thresholds to your risk appetite. Payroll bureaus typically run strict thresholds; e-commerce refunds may tolerate more partial matches.

FICA / POPIA context

A stored bank account verification record gives accountable institutions under the Financial Intelligence Centre Act (FICA) a timestamped, auditable record of customer due diligence. Under FICA Section 22, those records must be kept for 5 years. VerifyNow retains the audit trail on your behalf, so your compliance officer can produce evidence on demand.

Under POPIA, the personal information processed during a verification (ID number, name, bank account number) is protected personal information. Process it lawfully, keep it to the minimum required, secure it properly, and respect any Section 11(3) right-to-object request you receive from a data subject.

Legal basis — the short version

VerifyNow bank account verification is provided exclusively for fraud detection and fraud prevention purposes. That purpose is a prescribed purpose under Regulation 18(4)(b) of the National Credit Act and a recognised legitimate interest of the responsible party under Section 11(1)(f) of POPIA. For accountable institutions, it also supports FICA customer due diligence and record-keeping. Any other use is prohibited by our terms.

Next steps

• Walkthrough: read the companion step-by-step guide.
• Full field reference and schema: the bank account verification service page.
• API contract: API documentation.
• Pricing: current credit costs on /pricing#bank-account-verification.
• Other verifications: explore the full services catalogue.

Ready to start verifying?

Create a VerifyNow account at /register, top up credits on /buy-credits, and run your first bank verification in under five minutes. Whether you operate in Sandton, Cape Town CBD, Durban North, Pretoria East, Gqeberha or Bloemfontein, a real-time bank account check is the single best control you can add to your accounts payable, payroll and refund workflows — and the response fields above give you everything you need to make confident pay / review / reject decisions.

For the full response schema, see the bank account verification service page. For credit pricing, see /pricing#bank-account-verification. For integration examples, see the API docs.