Business customer KYB testing checks whether a bank’s systems correctly verify a business customer and apply the required onboarding controls. KYB means “Know Your Business”. Testing covers the business entity, its ownership and control, its representatives, screening results and the decisions that determine whether an application can proceed, needs review or must be declined.
What business customer KYB testing covers
KYB testing exercises the software and integrations used to establish who a business is and who controls it. A workflow may collect company registration details, verify the entity against a registry, identify ultimate beneficial owners (UBOs), check people or entities against screening sources, and route exceptions to an operations team.
The exact checks and decision rules depend on the institution’s policies, customer types and applicable jurisdictions. Compliance specialists define the expected controls; testers verify that the implemented workflow applies them as specified. Testing can include web or mobile interfaces, application programming interfaces (APIs), document-processing services, screening providers, case-management queues and customer records in the banking platform.
KYB differs from Know Your Customer (KYC), which focuses on an individual customer’s identity. Business onboarding can include KYC checks on directors, representatives and UBOs, alongside checks on the legal entity. Tests should verify that the system keeps these records and their outcomes associated with the correct business application.
How to test the KYB workflow
Start with approved requirements and decision rules. Identify the expected outcomes for each meaningful condition, such as a verified entity, a missing registration number, an ownership structure that cannot be resolved, a screening match requiring investigation, or a representative who lacks authority to act. Capture the conditions that lead to automatic progression, manual review, rejection or a request for more information.
Check integrations at their boundaries. Confirm that requests contain the required entity identifiers, responses map to the correct application, and timeouts or malformed responses produce the specified recovery path. A provider outage should not silently create a verified status. Retry handling should also avoid duplicate cases or conflicting decisions.
Verify state changes and records across the workflow. For example, an application awaiting documents should remain incomplete until valid evidence is received and processed. A manual reviewer’s decision should update the application status, retain the decision details required by the system, and prevent later steps from using stale screening results where the rules require a refresh.
Use synthetic test data wherever possible. Build linked records for companies, owners and representatives so tests can check relationships as well as individual fields. Avoid using real personal or business customer data unless there is an approved, controlled need and suitable protection. Include valid, invalid, boundary and ambiguous cases, with expected outcomes agreed by compliance and product owners.
Practical example
Consider a business account application with a company registration number, two listed owners and one authorised representative. A test can verify that the system retrieves the expected entity record, records both owners against the correct company, checks each required person through the configured screening flow, and routes a potential match to manual review. The application should remain blocked from account opening until the review decision is recorded.
Add failure cases: the registry returns no matching entity, an owner’s details are incomplete, the screening service times out, or a response refers to a different application identifier. For each case, assert the status, user-facing message, retry or review path, and resulting case record. Check that a failed lookup never produces a successful verification outcome.
Verifying results and managing risk
Review more than the screen shown to an operator. Compare the application status with API responses, case records and downstream customer data. Check audit events for the actions and decisions the system is required to retain, including who performed a manual review and when. Use requirements traceability to connect each control to its test cases and evidence.
KYB rules and external data can change, so regression tests should cover rule updates, provider contract changes and altered workflows. Keep test data current with the expected schemas and use environment checks to identify drift, such as a test environment pointing to a different provider version. A passing test confirms the behaviour exercised under those conditions; it does not, by itself, establish that the institution’s policies meet every legal obligation.
Frequently asked questions
How should KYB rules be tested when requirements differ by jurisdiction?
Represent each approved jurisdictional rule as a separately identifiable condition with its expected outcome, effective period and owner. Use decision tables or equivalent test specifications to check overlaps, gaps and changes without assuming one jurisdiction’s rules apply everywhere.
How can a team test a KYB provider outage safely?
Use a test endpoint, service stub or controlled fault injection to simulate timeouts and provider errors. Verify that the application enters the specified pending or review state, that retries follow the agreed policy, and that no success status is created from the failure.
Should KYB tests use real company records?
Synthetic records are usually preferable because they reduce exposure to customer data and can be designed to cover specific conditions. If real records are necessary, use an approved process with access restrictions, data minimisation and appropriate safeguards.
When should KYB regression tests be rerun?
Rerun relevant KYB regression tests after changes to verification rules, ownership handling, screening integrations, provider interfaces, case-management workflows or downstream onboarding systems. Include tests for affected dependencies and previously observed defects.