How to combine Bank Account Verification and KYB to assess business counterparties

Account verification and KYB checks can be combined by integrating two layers of information into a single assessment workflow. Each addresses different questions: the former provides details about the intended banking destination, while the latter adds context about the counterparty, such as its corporate identity, tax or legal status, relevant relationships, and potential reputational or regulatory signals.

Consider a company about to onboard a new vendor. The provided bank account exists, is active, and, where available information allows, can be confirmed to belong to the expected account holder. The banking side is verified, but a second question remains: what do we know about the company behind that account?

Adding KYB verification expands this evaluation, providing more context before activating a business relationship, onboarding a vendor, or executing specific transactions.

This is where Prometeo's Bank Account Verification and Risk Intelligence converge: solutions that allow you to evaluate the financial destination and add context about who is behind the operation within a single workflow.

KYB, or Know Your Business, refers to the processes used to identify and assess a business before or during a commercial relationship, based on each organization's risk, compliance, and due diligence policies.

A KYB review may require understanding a company's legal identity, registration or tax status, business activity, related individuals or entities, and whether there are signals that require further review.

Bank Account Verification covers a different part of the process.

Prometeo's Bank Account Verification checks account-related information and, depending on the capabilities available in each market, can determine factors such as account existence, status, and ownership.

In practice, it helps answer questions such as:

• Does the account exist?
• Is the account active?
• Does the account belong to the expected account holder?

KYB, by contrast, adds questions about the counterparty:

• What is the company's registered legal identity?
• What is its tax or legal status?
• What business activity does it conduct?
• Who is associated with the organization?
• Are there reputational or regulatory signals that require further review?

The functional difference looks like this:

These are different controls that can be part of the same process.

An account can pass the expected banking checks while the organization still needs more information about the counterparty before approval. The reverse can also happen: a business can pass certain corporate checks and provide an account that does not meet the customer's defined banking verification requirements.

That is why Bank Account Verification and KYB work as complementary signals before a business relationship or transaction proceeds.

Consider a B2B marketplace onboarding a new vendor.

The vendor provides its corporate information and a bank account for future payouts. Before activating it, the marketplace verifies the bank account information. The result confirms that the account meets the available checks.

That solves one specific problem: where the money will go.

But it does not necessarily answer other questions that matter to Risk or Compliance:

• What is the company's registered legal identity?
• What is its tax or legal status?
• Which individuals are associated with it?
• Are there relevant current or historical relationships?
• Are there signals related to sanctions, PEPs, watchlists, or adverse media?

Prometeo's new offering separates these layers by design. Bank Account Verification provides information about the account and its ownership, while Risk Intelligence adds data on the business, related individuals, and reputational or regulatory signals.

A positive Bank Account Verification result does not automatically mean a counterparty should be approved from a KYB or compliance perspective.

The reverse is also true. A reputational or regulatory signal does not automatically mean fraud has occurred or that the business should be rejected.

A match may require additional steps:

• Confirm that the identified entity is the business being assessed.
• Review available evidence.
• Assess the quality of the match.
• Determine whether the identified relationship is current or historical.
• Apply internal risk, KYB, or compliance policies.

The information serves as an input to the decision. The rules that determine what to do with that information remain with each organization.

Risk Intelligence adds corporate, tax, relationship, and reputational information that can be incorporated into KYB, onboarding, and due diligence processes.

The query starts with the market-specific Tax ID and the legal name of the company or individual being evaluated. From those inputs, the API can return structured information that can be integrated into other systems and workflows.

The exact content depends on the market, coverage, and available sources. Functionally, the information can be grouped into four areas.

1. Company identity

The first area answers a basic question: which entity are we evaluating?

Depending on available information, it may include:

• Tax ID.
• Country.
• Legal name.
• Trade name.
• Aliases or alternate names.
• Business activity.
• Tax regime.
• Legal entity type.
• Parent company or corporate group.
• Capital, foreign trade information, or change history, where available.

The goal is to provide structured corporate information that can feed directly into the assessment workflow.

2. Tax and legal status

A correct legal name alone does not describe a company's current status.

Depending on the market, Risk Intelligence may provide information such as:

• Registration status.
• Data source.
• Last updated date.
• Tax regime.
• Other available tax or legal information.

This adds context on the entity associated with the Tax ID used in the query.

3. Relationships

Assessing a business may also require understanding who is connected to it.

Available information may include:

• Shareholders or owners.
• Directors or officers.
• Related parties.
• Current relationships.
• Historical relationships.
• Relationship type.
• Relationship level.
• Information source.
• Relationship start or end dates, where available.

Risk Intelligence may also include aggregate indicators, such as total relationships, owners, or employees, depending on data availability.

This is especially useful when Compliance or Risk teams need more than the counterparty's legal identity. They also need context on the people and organizations associated with it.

4. Risk signals

The fourth area covers reputational and regulatory signals.

Risk Intelligence may query information related to:

• Sanctions.
• PEPs.
• RCAs (relatives and close associates).
• Watchlists.
• Adverse media.
• Relevant registries.

These signals should be treated as inputs to an assessment, not as an automatic decision.

A result needs context. The team may need to confirm that the match actually corresponds to the business being queried, review available evidence, and understand the nature of the relationship before applying internal policies.

Query traceability

In addition to business data, the response includes metadata associated with the query.

It may include elements such as:

• Query ID.
• Technical code or status.
• Match keys.
• Available evidence.
• Query source.
• Query date.
• Technical information about request processing.

The response is structured around company information, relationships, and query metadata so it can be incorporated into onboarding, KYB, and due diligence processes.

The flow can be represented as:

Integration means querying both layers and correlating the results within the customer's workflow.

The goal is not to turn Bank Account Verification and KYB into a single control. It is to use the information from each to answer different questions before a decision is made.

Risk Intelligence can be used as a standalone endpoint or as an add-on to Bank Account Verification.

A conceptual flow can be organized into five steps.

Step 1. Collect counterparty data

During onboarding or vendor setup, the system collects the information required to run the controls defined by the organization.

For example:

• Legal name.
• Tax ID.
• Bank account information.
• Other data required by the customer's internal policy.

Step 2. Verify the bank account

The bank account information is checked through Bank Account Verification.

Depending on the capabilities available in the relevant market, the organization may verify items such as:

• Account existence.
• Account status.
• Account ownership, where available.

At this stage, the question is:

Does the account we plan to use meet the expected checks before money moves?

Step 3. Query Risk Intelligence

Next, or in parallel depending on the customer's architecture, Risk Intelligence can be queried using the legal name and Tax ID.

The response adds available corporate, tax, relationship, and reputational or regulatory signals for that market.

The question becomes:

What context do we have on the counterparty associated with this transaction?

Step 4. Correlate the results

The customer's system can bring multiple signals together within its own workflow:

• Banking information.
• Corporate identity.
• Tax or legal status.
• Corporate relationships.
• Reputational or regulatory signals.
• Available metadata and evidence.

This allows the organization to assess the transaction with more context and maintain traceability into what information was checked before internal rules were applied.

Step 5. Apply business rules

The results feed into the policies defined by each organization.

Depending on its risk model, the process may lead to:

• Approval.
• Request for additional information.
• Manual review.
• Escalation.
• Rejection.

Risk Intelligence provides structured information to support that decision. The criteria that determine the next step remain in the customer's own rules and policies.

The complete flow can be represented as:

The value of keeping these signals separate becomes especially clear when the results do not align.

Instead of reducing the entire process to a single 'approved' or 'rejected' answer, the customer can define how to handle different combinations of information.

Case A: verified account + consistent corporate information + no relevant signals

The process may continue according to the organization's internal rules.

This does not mean the business has been certified as risk-free. It means that, based on the queries performed and the information available, no discrepancies were found that would trigger the customer's defined controls.

Case B: verified account + corporate discrepancy

The account may pass the banking checks while a discrepancy appears in the counterparty data.

For example:

• Differences in the legal name.
• Incomplete corporate information.
• Relationships that require further review.
• Registration data that does not match what was provided during onboarding.

In these cases, the organization may define actions such as:

• Request additional documentation.
• Review available evidence.
• Confirm the counterparty's identity.
• Escalate the case for manual review.

Case C: verified account + reputational or regulatory signal

A match on a watchlist, PEP list, sanctions list, or adverse media requires review.

The presence of a signal should not be treated, on its own, as evidence of fraud.

The team may need to:

• Review match quality.
• Confirm that the identity matches the counterparty being queried.
• Review the source and available evidence.
• Understand the identified relationship.
• Apply the relevant AML, KYB, or compliance policies.

Case D: the account does not pass the expected verification

The reverse can also happen: the company's corporate information is consistent, but the bank account provided shows a discrepancy.

The organization may then:

• Review the bank details provided.
• Request a different account.
• Reconfirm account ownership.
• Temporarily pause the process until the discrepancy is resolved.

Keeping these signals separate helps distinguish two fundamental questions: who is the counterparty, and which bank account will receive the funds?

Bank Account Verification helps clarify the banking destination. Risk Intelligence adds context on the counterparty.

When both layers are part of the same workflow, Risk, Compliance, Payments, or Operations teams can bring banking, corporate, relationship, and reputational information into the process before applying their decision rules.

Risk Intelligence can be used as an add-on to Bank Account Verification or as a standalone endpoint. It is designed for use cases such as:

• Merchant and business onboarding.
• Vendor and third-party assessment.
• Cross-border payments with regulatory exposure.
• AML/CFT and compliance screening.
• Processes that currently depend on manual information review.

These are among the primary use cases identified for Prometeo's solutions.

Risk Intelligence coverage and available data vary by market. Available markets and markets in development are tracked separately, so Risk Intelligence coverage should be evaluated independently from the international coverage of Bank Account Verification.

The result is a workflow in which each control has a clear role: verify the banking destination, understand the counterparty, and apply the organization's policies before deciding how to proceed.

Contact Prometeo to discuss how Risk Intelligence and Bank Account Verification can fit into your onboarding, due diligence, and third-party assessment processes.

What is KYB verification?

KYB, or Know Your Business, is part of the processes used to identify and assess a business. It may include corporate and tax information, business activity, related individuals, and reputational or regulatory signals. Specific controls depend on each organization's compliance and risk policies.

What is the difference between KYB and Bank Account Verification?

Bank Account Verification focuses on banking information: confirming whether an account exists or is valid, checking its status, and, where available, verifying account ownership. KYB adds information about the business involved in the commercial relationship. These are different controls that can be used together.

What information can be used to assess a business?

Depending on the market and available sources, this may include Tax ID, legal name, business activity, tax or legal status, owners, shareholders, directors, related parties, and signals tied to sanctions, PEPs, watchlists, or adverse media.

Can Bank Account Verification and KYB be integrated via API?

Yes. Prometeo Risk Intelligence can be used as an add-on to Bank Account Verification or as a standalone endpoint. The customer can incorporate both responses into its own workflow and then apply its approval, review, or escalation rules.

Does a risk signal mean a business should be rejected?

Not necessarily. A signal provides information that may require further review. The organization may need to confirm identity, assess match quality, review available evidence, and evaluate context before applying its risk or compliance policies.

Does Risk Intelligence replace a company's KYB process?

No. Risk Intelligence provides structured information that can be used within KYB, onboarding, compliance, and due diligence processes. It does not replace the organization's internal policies or, on its own, constitute the entire KYB process. The information serves as an input so each customer can apply its own controls and decision rules.