Using AI and rules-based matches for business registration verification

When we set out to build Persona’s Business Registration Verification (BRV) solution, we started by taking inventory of the KYB industry as a whole. What we discovered was a profound mismatch between how customers wanted to perform business registration verification and what was actually possible through existing solutions.

Customers want to be able to verify any business, in any jurisdiction, according to their own standards of what it means to be “verified.” But existing solutions typically offered a single product per country, making multi-jurisdiction verification a complicated prospect. Even worse, they tended to force a single, rigid standard of what verification should mean, regardless of nuances in data availability, jurisdictional requirements, and risk tolerance.

Our goal on the engineering and product side was to build a single BRV product that offered global coverage with fully configurable verification logic. Below, we take a look at the major challenges that informed our solution and explore how our three-pronged approach to BRV puts the power and control back in the hands of our customers.

Challenge #1: data coverage is fragmented

Verifying a business’s registration requires access to issuing and authoritative data sources that you can use to crosscheck the information you collect about a business.

Unfortunately, there’s no universal data source. Even within the same country, you can wind up with fragmented, inconsistent, and stale data. And the issues or inconsistencies can vary significantly by country and region.

Consider the differences in data availability between just three jurisdictions:

• In the United States, the IRS database contains a business’s employer identification number (EIN) and name, while each state’s Secretary of State (SOS) maintains a database with registration information.

• In Mexico, the country’s federal tax authority, the SAT, can’t provide full business addresses. You have to get that information from credit bureaus.

• In the United Kingdom, the Companies House Register is fully public and offers comprehensive data coverage, including data about the business’s address, status, ultimate beneficial owners (UBOs), and persons with significant control.

With this in mind, Persona’s BRV solution had to consider data fragmentation, cleanliness, timeliness, and the source’s authority on a jurisdiction-by-jurisdiction basis. We also needed a way to clearly communicate data availability and credibility. Otherwise, our customers might falsely fail businesses based on faulty or incomplete expectations or data.

However, despite the underlying variability, we knew that most KYB data sources can provide a business’s name, address, and registration number. So, those became the baseline for our BRV solution.

Challenge #2: definitions for “verified” can vary

Manually performing business registration verification often requires you to make a lot of decisions about what you learn about a business (the information) and the data landscape itself (the underlying sources).

At the simplest, you’re evaluating whether:

• The information the business submitted (their name, address, ID numbers, etc.) matches official records and registries.

• The source is reliable.

• Any inconsistencies fall within a range that’s acceptable to you and your organization’s risk tolerance and compliance requirements.

For this reason, how you define “verified” can differ significantly from how other businesses define it, and more importantly, how an individual BRV solution might define it.

In building Persona’s BRV solution, we wanted to give our customers the ability to define their own verification requirements so they could feel confident in answering the question: “have I seen enough, from the right sources, to trust this business in my context?”

Persona’s BRV uses three layers to model human decisioning

To address these challenges, we designed Persona’s BRV solution around three layers that can help you assess a business’s veracity.

• A match group is a collection of match requirements. It’s a way to express fuzzy matching on a particular field.

• Matching frameworks determine the underlying logic for match groups.

• Checks are additional, optional screenings that can improve results.

Here’s a closer look at each of the three layers.

Match groups

The first step in verifying a business’s registration is to determine whether the information it submits matches what’s in an issuing or authoritative database. But which information needs to match, and how closely it needs to match, depends on how you define a “match.” That’s where match groups come in.

A match group is a combination of risk-adjusted match requirements. It answers the question of “How similar does a particular user-submitted attribute (such as name, address, or registration number) need to be to an official record?”

There is, of course, no single way to define these requirements. You might, for example, decide that a match occurs if there is a full match between the business name and only a partial match on its registration number and address. Or, you might decide that a match exists if there is a partial match on the business’s name and its address.

Instead of forcing decisions on customers, Persona’s match groups allow you to build as many combinations of attributes and match levels (full, partial, and no match) as you wish. We even give you full control to define rules for fuzzy matching to account for things like typos and transpositions.

And because formats, registration number digit counts, and address structure vary by country, you can tailor your match groups to the realities of each jurisdiction you operate within. Or, you can leverage the default match groups that Persona designed for each country.

Matching frameworks

It’s also important to consider how you want matching to happen. Does the decisioning process need to be auditable and repeatable? Or is there flexibility for a more opaque process?

To give you full control over how matching occurs, Persona designed two matching frameworks you can deploy according to your needs: rules-based matching and AI matching.

Rules-based match groups

With rules-based match groups, you establish the internal logic that determines whether a match occurs. The precise control gives you a repeatable and auditable process, which is ideal for compliance-focused applications.

The main drawback is that it requires you to anticipate local inconsistencies when designing your match groups. We know this can be a heavy lift for some teams. That’s why, by default, Persona’s BRV comes preloaded with continuously updated insights gathered from extensive testing for any given region.

This means the latest observed and confirmed nuances of each country, such as the format of their business number to how their addresses are structured, are automatically reflected in the matching logic.

AI match groups

An AI match group is a collection of AI match requirements, where each expresses a fuzzy matching threshold for a particular field. Instead of using a deterministic algorithm, an AI match requirement can be defined as one of three match thresholds, also known as match level minimums: none, partial, or full.

For example, you can define a business name AI match threshold of partial, a registration number match threshold of full, and an address match threshold of none (meaning it’s not required but still processed.

These three AI match requirements can be combined into an AI match group. So if the underlying AI provides a fuzzy match of at least partial for the business name and full for the registration number, the AI match group is satisfied, and the AI is considered a match against the business record.

While AI-matching is often quicker to get up and running, it isn’t fully auditable, making it harder to justify to a regulator. With this in mind, it may be better suited to fraud- and conversion-focused applications. We’ve also seen customers use AI matching as a fallback to rules-based matching.

Checks

In most cases, match results don’t address all of the questions you need to answer to truly verify a business. For example, you might want to know whether a business is active and what type of filing status it has.

Checks are additional screenings that execute independently of matching but draw on the same authoritative sources. They offer a pass/fail result that you can consider alongside match results.

Your compliance requirements and risk tolerance can determine which checks you run, and the checks can include things like:

• Active business detection: Is the business currently active or has it ceased operations?

• Associated persons comparison: Do the associated persons or UBOs listed by the business match official records?

• Registered agent address detection: Does the business’s address use a registered agent address?

• Valid registration number format: Does the registration number supplied by the business match the expected format for the jurisdiction?

Consider a bank that offers commercial deposit accounts in the US. It uses BRV to determine that the information provided by a new customer matches official records. But an additional check flags that the principal business address belongs to a third-party registered agent service.

That’s not necessarily a concern on its own since many businesses use and share registered agent service addresses. However, the bank might flag or reject the application because registered agent addresses are strictly for legal intake.

Automate and configure your BRV and KYB

Business registration verification is an essential piece of your KYB strategy, but it’s also only a piece. Just because a business passes BRV, that doesn’t necessarily mean that you should engage with it. And just because it fails doesn’t mean you shouldn’t. In all likelihood, additional checks, screenings, and reviews will need to take place before you can make a final determination.

Workflows address this need by enabling you to automatically route users to follow-up steps based on their BRV results. A passed BRV, for example, might trigger enrichment via business adverse media screening, watchlist checks, VAT validation, document verification, credibility reports, and ultimate beneficial owner (UBO) verification. A failed BRV, on the other hand, might trigger manual review or another backup option.

Because our goal is to empower you to build a truly bespoke KYB program, the logic underlying Workflows is fully self-serve and configurable. You can even use conditional logic to establish separate workflows for different scenarios, such as whether a business passes BRV with rules-based or AI-based matching.

Want to learn more about how Persona’s BRV and KYB solutions can help you meet your compliance and risk management goals? Contact us today to speak with a member of our team or request a free demo.