Account verification (BANV/AVS)

How Root verifies bank accounts of policyholders


Account verification consists of checks that run against bank accounts provided for debit order payment methods. This is an optional configuration on Root.

Other common names for this type of verification include:

  • BANV: Bank Account Verification
  • AHV: Account Holder Verification
  • AVS: Account Verification Services

Account verification checks

Account verification checks are an optional setting on your organisation which you can opt-in for when you get set up with Root. This configuration will be applied to all product modules in the organisation.

When a debit order payment method is added/updated on a policy, Root will immediately send this to Paysoft for verification. There is an average 2 hour response time due to these checks being managed in batches which are processed throughout the day. This means the BANV response is not real-time.

In the event of an issue with the batches, an alert will be triggered and sent to the Root billing team to investigate and initiate the recovery protocol. This means that in extremely rare circumstances account verification can take up to 48 hours. However, the norm is a 2 hour response time.


BANV Costs

Account Verification does incur costs ranging from R1.87 to R3.38 inclusive of VAT bank and volume dependant. This is based on 2021 pricing which is subject to change.

Which banks can be verified?

The following banks are supported via the Root integration:

  • ABSA
  • African bank
  • Bidvest bank (old mutual)
  • Capitec
  • Discovery bank
  • FNB
  • Grobank
  • Investec
  • Mercantile bank
  • Nedbank
  • Standardbank

For banks that do not support BANV, such as Tymebank or Ithala, or when BANV is disabled for an organisation, the payment method's banv_status will default to verified, and the auto_banv_verified field on the payment method will be set to true to indicate that a BANV check was not done for this payment method.

What checks are done?

There are two main types of account verification checks at Root, hard & soft checks.

Hard checks

The hard checks must be passed in order for the bank account to be verified for premium collections. If any of the hard checks fail, the bank account will display a failed verification status and no premium collections will be done against the account until resolved.

CheckMeaningCommon failure reasons
Account must existThis means the account number must be valid and belong to the banking institution.

If the account does not exist the below checks will not be executed.
• Mistyped account number.
• Incorrect bank selected (e.g. FNB account number with ABSA selected as the bank).
ID number or company registration matchFor natural person bank accounts:
The account holder and ID provided must match on the bank's side. When adding a bank account to a policy the default option will be to validate against the policyholder's ID, with an option to provide a different account holders ID.

For business bank accounts:
The registration number of the business must match that stored on the bank's side.
• Bank account does not belong to the policyholder and no account holder ID was provided.
• Bank account does not belong to either the policyholder nor the account holder ID provided.
• Bank account does not belong to the registered company that owns the policy.
Account is openThe account must be active.• Account has been actively closed by the account holder.
• Account has been closed by the bank due to inactivity.
Account accepts debitsThis is critical to ensure we can collect premiums from the bank account.Certain types of savings accounts don't allow external debits.

Soft checks

In addition to hard checks, soft checks are also done against a policyholder's account. However, if they fail it will not prevent a bank account from being approved for premium collection:

Initials matchDoes the bank account holder's initials match that of the policyholder.
Surname/Company name matchFor natural person bank accounts:
Does the bank account holder's surname match that of the policyholder.
For business bank accounts:
Does the registered company name on the policy match that on file at the bank for the account.
Account accepts creditsDoes the account accept external credits, which means money can be returned to the bank account i.e. refunds.
Open for more then 3 monthsHas the bank account been opened for more than 3 months. This is a risk check used for risk management.

Adding a bank account holder's ID number

One of the hard checks for account verification is ensuring that the bank account holder is validated against that of the details stored on the policy. The default setting is to run the checks against that of the policyholder's identification number, however in the event that the bank account holder is a separate entity such as a spouse or parent, their ID number can be provided for the check:


When providing/editing bank details on the dashboard a new checkbox displays "The above billing details do not belong to the policyholder". If checked, an Account holder ID number field will display and you can enter their ID number.


The debit order can be created via the API. An example request can be seen below.

curl \
  --request POST \
  -u test_key_tYILz1640w9q5n5kNQUZ: \
  -H "Content-Type: application/json"
  -d \
    "type": "debit_order",
    "bank_details": {
      "account_holder": "Erlich Bachman",
      "account_holder_identification": {
        "type": "id",
        "number": "0106032817364",
        "country": "ZA",
        "expiration_date": "2027-10-05"
      "bank": "absa",
      "branch_code": "12345",
      "account_number": "123456789",
      "account_type": "cheque"
    "policy_ids": [":policyholder_id"],
    "billing_day": 23

Reporting on payment methods

To monitor the payment method statuses of your policies you can use the Root export tooling to retrieve the relevant data. Blocked/failed verification payment methods are also visible on the Root dashboard under the Payments tab.

On the Root dashboard, head to Settings → Exports → Export Templates and build a template using the Payment Methods data source.

For debit orders, the bank_details object contains useful insights such as the banv_status.

  "bank_details": {
    "account_holder": "Test Human",
    "account_holder_identification": null,
    "bank": "capitec",
    "branch_code": "12345",
    "account_number": "12435465346",
    "account_type": "cheque",
    "banv_status": "pending",
    "blocked_reason": "Payment failed with response: No authority to debit", //Example
    "banv_response": {
          "account_number": "12435465346",
          "initials": "T",
          "name": "T Human",
          "flags": "N ",
          "result": "A/c doesn't exist",
          "id_number": "9001011111088",
          "reference": "ed379030-f5dd-40f4-aa0d-a0eccd71d4cf"
          }, //Example
    "payment_method_id": "416e59a0-dca1-4db8-81e4-f21faa55e913"

The following table outlines the banv_status meanings. If no bank account has been saved on the policy the payment_method value would equal null.

BANV StatusDebit Order MeaningCredit Card Meaning
pendingAwaiting verification response from the bank.Not possible - Account verification is not run on card payment methods.
verifiedBank account has passed hard checks and premium collections will be attempted.3DSecure has passed.
failed_verificationBank account has failed >=1 hard checks. No premium collections will be attempted.Not possible - 3DSecure must be passed prior to a card being saved on a policy for premium collections.
blockedEither the bank account holder has actively blocked the debit order via instruction to their bank or the bank has blocked the collection attempt due to too many failures in a row.Not possible - Credit cards cannot be blocked on the platform.