If I had a pound for every time someone asked me this question, I’d have enough to fund a global KYB registry (and maybe even keep it updated).

“Which data points do we have to get from a verified source and what can just be submitted by the business?”

I’ve search and searched for a single guide that answers this exact question but nobody seems to have written one. So, I thought it may as well be me.

It sounds simple, right? But of course, it’s not. The devil is in the data and the answer depends on three things:

• Where the entity is based
• What your regulator expects
• And whether that data even exists in a so-called “trusted source”

You might be asking yourself what the difference is……..

Verified data is information obtained from an independent, authoritative source like a government registry, regulatory database or trusted third party aggregator. Some examples of these include the likes of Companies House or Dun & Bradstreet.

Self declared data on the other hand is information provided directly by the business during onboarding often via a form or questionnaire or sometimes even through an excel spreadsheet. This information isn’t verified by an external source.

Why does this matter? Because chasing the “perfect source” for every data point might sound rigorous but in reality, it creates unnecessary friction, frustrates your ops team and doesn’t always make your process any safer or more compliant.

Of course, the more information you can pull from an independent, verified source, the better. It builds trust, reduces fraud and keeps regulators happy but it’s not the whole story. Sometimes the perfect source doesn’t exist or gives you less insight than you think. And when that happens, self-declaration isn’t just acceptable, it’s necessary.

Some people still believe every country has a perfect UBO registry with all the details you need but that’s the dream, not the reality.

I remember a colleague who was onboarding a business in the Cayman Islands. They fully expected to pull UBOs from a registry but of course that data doesn’t exist (which is often exactly why companies choose that jurisdiction). In these cases, your onboarding process has to adapt to capture what’s missing without falling apart when registry data isn’t there.

I also remember speaking with someone previously who was absolutely adamant about only using registry sourced data. In their view, data from an aggregator just wasn’t acceptable. The problem? The registry offered barely any information at all. In the end, they had to rely on self declared data anyway even though the aggregator had richer, more up to date information from the start.

What Must Come from a Trusted Source and What That Actually Means

Regulators expect certain information to come from an authoritative source, like a registry or licensed data provider, if it exists. These are the core identifiers, the facts that define ownership and legal status.

Examples:

• Legal entity name and address
• Incorporation date and registration number
• Status (active/dissolved)
• Directors and officers
• Shareholders and UBOs (where registries exist)
• Formation documents
• Industry codes

Verified contact details are also important but here’s the nuance: registries rarely have phone numbers or emails. So verification usually means validating details the business gives you, like checking the domain for the email address or confirming the phone number works.

Where does this come from?

• Official registries like Companies House, SEC, ASIC etc
• Third-party aggregators like D&B, Enformion, KYCKR

Self-Declared Data: Not a Risk, a Requirement

Some details will never come from a registry and in many cases they’re often the most important for understanding risk.

Examples:

• Nature of business activity
• Purpose of the account
• Expected transaction volumes
• Source of funds/wealth

And here's the important bit, just because a data point is self-declared doesn’t mean it’s unchecked. You may not verify it from a registry but you can still validate it by testing logic, asking for documentation or comparing it with known patterns. That’s not cutting corners, it’s good compliance.

And here’s the myth to kill right now, if you can’t get registry data, the process stops….. wrong. If a registry doesn’t exist or an aggregator can’t provide coverage for critical information like core business information or beneficial ownership information then self declaration isn’t just acceptable, it’s expected.

This is not a compliance failure. In fact, regulators expect it. They know global data coverage isn’t perfect. What matters is how you control and validate what’s declared.

Here’s what best practice looks like:

• Apply a risk-based approach to determine when extra checks are needed
• Request supporting documents such as shareholder registers, structure charts or declarations
• Complete PEP, sanction and adverse media screening
• Keep a clear audit trail showing your reasoning and actions

The message here is self declaration is not a bad thing and can work when combined with verification steps. Regulators understand these gaps but what they don’t accept is zero effort. Self declaration isn’t a weak point, it’s part of a strong and flexible KYB process when validated properly.

Registries: A Good Start, But Not the Whole Picture

Registries are often seen as the “source of truth.” They’re important, but they’re not perfect. Many rely on businesses to self-report updates and in some jurisdictions (you know which ones), updates aren’t enforced. That means records can be out of date.

I’ve seen:

• Former directors still listed
• Dissolved companies showing as active
• UBO details from five years ago

Does that make registries useless? No, it just means they’re one input and not the single point of truth.

Third Party Aggregators: The Unsung Heroes of KYB

Here’s the reality: a single registry gives you a single view. Aggregators pull from multiple sources, normalise the data and enrich it so you can scale onboarding globally.

What they offer:

• Broader coverage across jurisdictions
• Enriched data beyond what a single registry provides
• Consistent formats so your processes don’t break

And here’s the key point: regulators don’t require a direct, real-time registry connection. They require data that’s reliable, up to date and independently sourced. Using a reputable third-party provider is not just acceptable, it’s often the most practical and scalable approach.

That’s why at Detected, we support data from registries, aggregators and self-declared sources because real onboarding isn’t one size fits all.

Registry vs Aggregator: Stop Chasing the Wrong Source

This question comes up all the time: “Does the data have to come straight from the registry?” and the short answer is no.

One of the things that’s really surprised me since joining Detected is just how many compliance teams focus obsessively on “direct-to-registry access.” They treat it like the gold standard and spend huge amounts of time chasing it, even when it slows onboarding, adds no value and in many cases, delivers less information than an aggregator. It’s wasted effort pretending to be best practice.

Regulators care about quality, not the pipe you use. But there are exceptions:

• High-risk or EDD cases
• Where your policy says so
• When a registry has known gaps and you need a second check

Even FATF guidance is clear: take “reasonable measures” to verify beneficial ownership often by consulting multiple sources. That includes registries, reliable third parties and supporting documents. It’s not an absolute requirement to use multiple sources every time, but it’s best practice when risk dictates it.

If your KYB policy assumes everything must come from a registry, you’re not actually being more compliant, you’re just being less adaptable. Rigid sourcing requirements don’t impress regulators. What does impress them is how you handle the reality of inconsistent global data. Being compliant means knowing when to verify, when to validate and when to adapt without compromising integrity.

Just because a regulator says data should be sourced, it doesn’t mean it always can be. When it’s not available and in many countries it’s not, self declaration isn’t just allowed, it’s the only option.

When the Data Doesn’t Match — Which Source Wins?

Sometimes it’s not about what source you use but what happens when the sources don’t agree. One registry says a director has resigned, another says they’re still active and the business gives you a different name entirely.

This happens more often than you’d think especially in cross-border cases or when updates haven’t flowed through multiple systems. That’s why your KYB process needs more than a good data provider. It needs a clear policy.

Here’s what that could look like:

• Define which source takes priority by default
• Use a second source or document request when the risk level is higher
• Keep a record of the discrepancy and how you resolved it

Conflicting data doesn’t mean your process is broken but not having a plan to deal with it does.

What Regulators Really Expect (It’s Not What You Think)

No major regulator explicitly requires a direct, real-time registry connection. What they want is data from an independent, reliable source and that can absolutely include third-party aggregators.

Even when regulators say something must be sourced, that’s only if the data is available. When it’s not and in many countries it’s not, self declaration is simply the only option. What really matters is how you validate and document it.

Here’s how some key regulators draw the line:

European Union – AMLD5/6

The EU emphasises transparency through UBO registers but it acknowledges gaps

• Must be sourced: Company registration details and UBO from national registries (where available)
• Can be declared: Nature of business and projected turnover
• Note: Firms are expected to flag discrepancies between what a client says and what the registry shows.

United States – FinCEN CDD Rule

• Can be declared: UBO information via a certified form
• Must be verified: Identity of those individuals (via ID), and legal existence of the business
• FinCEN doesn’t require cross-checking UBO data against a central registry (yet), but does expect a risk-based approach.

United Kingdom – FCA

The FCA puts clear expectations on verifying core company data.

• Must be sourced: Business registration info (Companies House), directors
• Can be declared: Source of wealth, business purpose (though these may need supporting docs for high-risk cases)
• Firms are told to test the plausibility of declared data, even when it's allowed.

Singapore – MAS & Australia – AUSTRAC

Both regulators require core identity and registration data to come from official sources.

• Must be sourced: Business registration, director identity, license status
• Can be declared: Use of services, transaction volumes, source of funds (with documentation if needed)

Regulations Are Grey - Interpretation Is the Risk

One of the biggest challenges in KYB compliance isn’t the lack of rules or the rules being too strict, it’s that they’re not always clear and how differently those rules get interpreted.

Terms like “reasonable measures,” “independent source,” or “must be sourced” sound official but they are intentionally broad leaving room for interpretation. They give you room to apply a risk-based approach but they also leave space for confusion and that’s where teams get stuck.

I’ve seen some firms interpret “sourced” as “must be from a registry, no matter what,” even when the registry has no useful data. Others treat any self-declared data as automatically non-compliant, but neither is quite right.

The reality? It’s not about following a perfect rulebook. It’s about using good judgement, documenting decisions and being able to defend them when it counts.

Pros and Cons at a Glance

Verified Data

• Pro: Independent, trusted source, satisfies regulators, reduces fraud
• Con: Not always available, can be outdated, adds cost and complexity

Self-Declared Data

• Pro: Fast, flexible and often the only source for forward-looking info
• Con: Higher risk of manipulation, requires validation

Ongoing Monitoring: KYB Doesn’t Stop After Onboarding

A lot of KYB processes are great at onboarding and then… that’s it. But directors change, companies dissolve and UBOs move behind new structures.

Regulators are starting to expect more than just a snapshot. Ongoing monitoring especially for material changes like company status or sanctions hits isn’t just nice to have anymore. It’s where good KYB becomes great risk management.

This doesn’t mean chasing data manually every month. It means building a process that flags changes when they matter. That might come from:

• Data providers with change detection alerts
• Scheduled periodic reviews
• Event-based reviews (new director, transaction anomaly, adverse media hit)

The goal is to stay in control without overwhelming your team. Monitoring should support your process, not slow it down.

Your KYB Process Doesn’t Need to Be Perfect - Just Defensible

The goal isn’t perfection, it’s defensibility. Regulators know the gaps and they expect you to:

• Understand your sources
• Apply risk-based checks
• Document everything

That’s the difference between a KYB process that scales and one that collapses under manual reviews.

And here’s where KYB often breaks down, the policy says one thing and the actual process does another. I’ve seen a company's policy insist on registry source UBOs everywhere but in practice, they still rely on self declaration, because they have to. If your process can’t keep up with your policy, you’ve got a risk.

The Distinction That Will Make or Break Your KYB Process

Getting this wrong can lead to breaches, fines or reputational damage. Regulators regularly audit how data is collected and verified. There is also an element of risk and fraud prevention as self-declared data is easier to falsify. Verifying identity, ownership and registration helps filter out shell companies and bad actors early. This also helps with operational efficiency as clarity on what must be verified vs. what can be submitted simplifies onboarding flows and reduces unnecessary friction.

When ops teams aren’t sure what can be self-declared or what needs to be sourced, they tend to over-correct. That either means chasing unavailable data or slowing down onboarding while they wait for guidance. Clarity reduces friction not just for compliance but for the people actually running your onboarding.

When you know what data must be sourced vs declared, you stop wasting time chasing things that don’t exist and start building a process that actually works.

Budget vs Control: Don’t Just Add Headcount, Add Better Systems

One of the traps compliance teams fall into is trying to fix broken KYB flows by throwing more people at the problem. More analysts, more manual reviews and more tickets. But it’s not always a people problem, sometimes it’s a system problem.

Even with a tight budget, it’s worth investing in tools that give your team real visibility. That means centralising data sources, automating low-risk checks and making it easier to escalate the edge cases…. not every onboarding needs a task force.

A better system will give you more control, fewer mistakes and less stress for your teams. And if you’ve got the right tools, you might not need as many of them in the first place.

Three Things to Keep You Compliant (and Sane)

The three quick takeaways are:

1. Registries matter, but they’re not perfect and no regulator requires registry-only data.
2. Third-party aggregators are a scalable, regulator-accepted solution.
3. Self-declaration is fine, when combined with risk-based validation.

When it comes to KYB, clarity is everything. Understanding which data must be verified and which can be self-declared is a critical part of building an effective and compliant KYB process.

It’s not about blindly trusting a source or a form. It’s about having the right controls, cross-checks and documentation in place to show you’ve done your job. These are the kinds of details that make or break a KYB program and not just in terms of compliance, but in how smoothly and scalable you can operate.

Different regulators might draw the line slightly differently but the principle is always the same: Trust must be built on facts, not just forms.

If you’re still trying to figure out how to balance data sources vs self declaration in your KYB, I hope this helps because this is what we help teams solve every day.

Getting KYB right isn’t just about compliance, it’s about speed, scale and sanity. If your process grinds to a halt every time a registry is missing, you’re not solving compliance…. you’re creating chaos.