Perpetual KYC: Know Your Customer Forever
TL;DR
- Entity resolution supports KYC and AML programs by linking fragmented customer records, aliases, source-system data, and relevant risk signals into a clearer identity view for review and monitoring.
- For perpetual KYC, the important shift is from a one-time snapshot to an ongoing process: records are resolved and assembled as new data arrives, then screening, monitoring, and investigation workflows retrieve the current resolved context at query time.
- Entity resolution is data infrastructure for KYC and AML teams, not a legal guarantee. Financial institutions still need their own policies, controls, validation, escalation paths, and regulatory advice.
Table of Contents
- Decision guide
- The downfall of CAMPARI and ICE
- Identity, suitability, and risks: the many faces of a customer
- A changed point of view: getting the right perspective
- Doing it at scale: chowin’ down on Big Data
- Takeout thoughts on pKYC
- Short answer
- Why KYC needs resolved identity context
- How perpetual KYC changes the data problem
- Where entity resolution helps AML and sanctions review
- What financial institutions should validate before adoption
- Frequently Asked Questions
Decision guide
| KYC or AML need | How entity resolution helps | Watch-outs |
|---|---|---|
| Customer onboarding | Links identity attributes across internal and external sources so reviewers can inspect a fuller customer picture. | Do not treat a match as automatic approval or rejection. Keep review rules, evidence, and escalation paths clear. |
| Perpetual KYC monitoring | Updates the resolved customer context as new data arrives instead of waiting for a periodic refresh cycle. | Define which changes should trigger review, what evidence analysts see, and how false positives are handled. |
| Sanctions, PEP, or watchlist screening support | Helps connect aliases, spelling variants, addresses, and related records that may otherwise appear disconnected. | Screening outcomes depend on data quality, list quality, matching thresholds, and human review. Entity resolution does not remove those responsibilities. |
| Large-scale financial-services data | Creates a reusable resolved identity layer for onboarding, monitoring, investigations, customer service, and analytics. | Validate latency, data freshness, privacy controls, and audit needs in the institution's own architecture. |
| Reducing unnecessary customer re-requests | Makes already-held context easier to retrieve when it is reliable and permitted for the workflow. | Customer contact, consent, retention, and regulatory requirements still depend on the institution's policy and jurisdiction. |
In Neal Stephenson’s classic novel, The Diamond Age, Judge Fang and his Confucian colleagues need a break after a hard morning in a Shanghai courthouse. So they head down the Bund to a restaurant they refer to as “The House of the Venerable and Inscrutable Colonel”.
It’s obvious to any reader that it’s a KFC.
We started with this because KFC is a common misreading of an equally common problem for banks and other financial institutions: KYC, or Know Your Customer. Legislation aimed at preventing fraudulent use of the financial system (ah, what a dream) by making sure every accountholder is legitimate. The legal frameworks differ around the world, but almost every country now has KYC laws in place, often alongside AML (Anti Money Laundering) acts.
Mention the acronym to your non-banking friends, and they’ll probably feel hungry for hot wings. But in reality, KYC is a vast and complex headache for banks everywhere, thanks to the bucketloads of data associated with nearly every individual on the planet.
KYC involves checking people’s identities to make sure they are who they say they are … because bad guys have an incentive to bend the truth. And in its latest iteration – pKYC, or perpetual Know Your Customer – it means maintaining up-to-date records, as an ongoing process, forever … without driving customers crazy with constant requests for “more information”.
In other words, pKYC combines a huge need for data … with limited options for collecting it.
Relax, KYC fans. There is a solution. It involves database technology – but not the rigidly-formated, manually-gathered kind you’re probably familiar with. And of course, it’s nothing to do with fried chicken.
Or is it?
Let’s go through the issues facing pKYC … with notes on our method for solving them.
The downfall of CAMPARI and ICE
As a drink, it’s probably too high-falutin’ for the dear Colonel. But ask any banker of a certain age what Campari & Ice means, and they’ll quote: Character, Ability, Means, Purpose, Amount, Repayment, Insurance & Interest, Commission, Extras.
It’s a checklist they used to use when extending financial services like loans. It seems to cover everything, doesn’t it? Yet you don’t see this definition much these days.
Why? Because barely any letter of the acronym addresses nefarious intentions: it’s just about whether he’ll be profitable for the bank. Which is why, for several decades, banks from the Caribbean Coast to Brickell Street were happy to take suitcases full of hundred-dollar bills to open an account, no questions asked.
Fortunately (unless you’re a frustrated criminal) that’s changed. To today’s bank, the source of funds is as fundamental as the amount. So it’s bottoms-up to CAMPARI & ICE, which didn’t hit the spot at all.
Whenever you answer a bank questionnaire, or face probing phone calls about where your money came from, the bank is doing KYC on you. It’s not enough that you seem a respectable person; they have to know (or at least have a plausible idea) that you’re legit. (Don’t treat them harshly when they call; they have no choice, and the job’s often done by a junior person.) Modern KYC divides into just three areas: identity, suitability, and risk.
Identity, suitability, and risks: the many faces of a customer
KYC may be a less cool acronym, but it has the right goal in mind.
While the term has been around since the 1970s, it hit its stride after the September 11 attacks in New York. Suddenly – and understandably – governments wanted to know a lot more about you than the color of your money. So the aims of KYC were much more outward-focused:
- Proving the person’s identity as an individual – including their background
- Assessing their suitability as a banking customer – and their real intentions
- Managing the risks of maintaining a banking relationship with them
The big question here is: who is that person you’re KYCing, really?
Our Kentucky icon provides an example. Sticking with finger-lickin’ for a moment: everyone from bustling Atlanta to rural China knows Colonel Sanders as a friendly, chortling, twinkly-eyed gentleman in a white suit. The sort of person you could introduce to your grandmother.
Caveat emptor.
Because in reality, Harland Sanders was a foul-mouthed roughneck you wouldn’t invite to the Governor’s Mansion, ever. He was hot-tempered, his capacity for swearing was legendary, and he didn’t much care who heard it. He’d been in the Army, and while he wasn’t one to start a fight, he didn’t run away from one either, once threatening to “blow [a competitor’s] ^%$&! head off”. (In the end, he shot him in the shoulder instead, albeit under extreme provocation – the man had been painting out a sign that directed travelers to the Colonel’s business.)
Let’s face it, if your early life included stoking coal, pumping gas, and getting into shootouts from the age of 13, you’d drop the occasional f-bomb.
And there’s the problem. Customers have many faces. They’ll show one face when they complete your KYC documents. Another when they’re with friends at the local Bar-B-Q. And if they’re bad actors (in the criminal sense), the face they show to you may be completely made up.
But you can’t send questionnaires to the customer’s associates and colleagues, even if you know who they are. And they probably wouldn’t reply, anyway. So that’s our problem #1: effective KYC needs a 360º view of the person.
The answer: you need data from multiple sources, joined together into a single picture of the customer that confirms he is who he says he is and the information he gives about his funds is accurate. This is the basis of entity resolution, that thing we do at Tilores.
Entity resolution looks at different datasets for clues that associate different “objects” – say, a customer record in a database – with others that share its characteristics, building a more comprehensive picture of that customer as it goes. This is harder than it looks: think of how many people share the same surname, or how many variants exist of a common given name. Which is why many financial institutions don’t even realize it’s possible. But trust us: with modern methods, it’s possible to “resolve” your customer from a variety of datasheets - sanctions lists, for example – and cross-check what they’re saying time and again, automatically.
A changed point of view: getting the right perspective
On to the next KYC issue. Even if you’ve got that 360º view from multiple sources of data, the context in which you’re viewing that customer matters.
The Colonel illustrates the problem once more. Next time you pass a KFC, let your gaze rest on the logo image: Harland Sanders’ smiling face, neck bedecked in a bootlace tie. Now imagine his necktie not as an item of clothing, but as a stick man’s body with the Colonel’s head on top.
The illustration hasn’t changed. The data doesn’t differ. But you’ve just seen the same piece of artwork … in a completely new way. A fresh perspective on the data changed your perception of it.
It’s the same with the people KYC procedures were designed for: “Politically Exposed Persons”, or PEPs. They often wield power and wealth in their home nations, with opportunities for embezzlement and fraud – but seem perfectly respectable on the surface. So getting the correct perspective on customer data is another huge challenge for KYC.
So problem #2: how can KYC look beyond the seemingly respectable individual, and check if he’s really a dancing stick man?
The answer here: you don’t do it as a snapshot, but as a rolling and repeated process over time.
That’s what perpetual KYC aims for: a smooth process of continuous checking, matching, and re-checking data from multiple sources, so the chances of missing red flags shrivel.
If a PEP’s name pops up on a watch list the month after you did the last KYC check, or a mid-ranking civil servant suddenly claims a rich long lost Uncle is buying a $10m penthouse in Miami, making those checks ongoing without end will expose them. No longer will passing a single check give them a free pass for years to come.
Again, entity resolution is your tool of choice. The great thing about using entity resolution: this overabundance of data is actually an advantage. Because when you’re doing KYC not as a one-off check, but an ongoing process, even one small piece of off-key information looks like an outlier worth investigating.
Yes, genuine fraudsters and shysters are exceptionally good at hiding their true natures. But with pKYC, they have to be lucky all the time. You only have to get lucky once.
And you’ll never look at a KFC logo the same way again, will you?
Doing it at scale: chowin’ down on Big Data
All this ongoing checking sounds like a lot of work. And conceptually this is where a lot of ideal-looking solutions fall down. Because what might be possible for one small bank with a thousand customers doesn’t scale to an international financial institution with billions of bucks under management.
Adding to this, KYC can’t be selective. For fairness and full compliance, you have to apply the same rules to everybody on your database. Those who come researching a mortgage. Who apply for a credit card. Who want to open an account. Everyone.
And as different organizations build different lists of people with question marks over their heads, the complications increase further. What if someone’s on one list, but not others? What if he’s known by multiple aliases? Or has several passports? Worst of all is that an innocent person with the same name gets the blame for the foul play of his namesake.
So as datasets get bigger and bigger, it gets less and less easy to spot the criminals among the honest traders. Because the whole point of criminal activity is to look exactly like the average Joe. To have a profile that raises no suspicion, that doesn’t invite further scrutiny.
This is KYC problem #3: the sheer size of the data landscape.
It’s a lot more complex than getting a mix of 11 herbs and spices right, and even that took the Colonel nine years. (And presumably a lot of cussin’, too.)
For the third time, entity resolution delivers. The beauty of our entity-matching solution at Tilores is that as you scale to span more and more data, the workload on the software doesn’t scale with it. For reasons we won’t go into here, we’re talking <150ms per query, every time, no matter how complex or far-reaching the dataset gets.
We’ll add this doesn’t happen with all entity resolution solutions. But we designed Tilores specifically with this scaling problem in mind. Which makes it specifically useful in a pKYC scenario, too.
Takeout thoughts on pKYC
Let’s wrap up with a return to the House of the Venerable and Inscrutable Colonel. The sci-fi author’s schtick was that Confucian officials admired Harland Sander’s wise-looking face and discreet approach to his secret blend of eleven herbs and spices.
Yet every franchisee knows the fabled 11 are just everyday ingredients available in bulk at every Wal-Mart. The real secret to the recipe was the Colonel’s use of a old-style pressure cooker – hard to handle, and prone to explode. (No wonder the Colonel swore a lot.)
It wasn’t the seasoning, but the method that mattered. And how you approach your KYC obligations is surprisingly similar. You can do it piecemeal, wasting time and resources trying to make sense of an ever-shifting set of data points spanning the world … or see that data as an opportunity, and use entity resolution to authenticate each customer reliably and repeatedly without having to bother them. You know all about them without having to ask. Just as a hardworking franchisee knows that anytime a station wagon draws up, they’re going to order the Family Bucket.
Maybe entity resolution for perpetual KYC isn’t so different to KFC after all.
For some Know Your Customer entity resolution that’s finger-lickin’ good, talk to our data experts at Tilores.
Short answer
Financial institutions use entity resolution in AML and KYC workflows to connect records that may describe the same customer, counterparty, beneficial owner, or related identity across multiple datasets. That helps onboarding, screening, monitoring, and investigation teams work from a more complete identity view instead of isolated records.
In a perpetual KYC model, entity resolution helps keep that view current. New records, changed attributes, aliases, and relevant risk signals can be resolved and assembled at ingestion, so query-time checks retrieve current context for review rather than relying only on a past onboarding snapshot.
Why KYC needs resolved identity context
KYC workflows often depend on records that arrive from onboarding forms, core banking systems, watchlists, sanctions sources, case tools, and third-party datasets. Each source may describe the same person or organization in a different way.
Entity resolution gives those workflows a way to link related records into one reviewable identity context while preserving the underlying source records and match evidence.
How perpetual KYC changes the data problem
A one-time KYC check can become stale as customers move, companies change ownership, aliases appear, or new risk information becomes available. Perpetual KYC treats customer understanding as a continuing data problem.
For that model, the resolved identity view needs to keep updating. Records should be resolved and assembled at ingestion, then retrieved as current context when monitoring or investigation workflows query the customer.
Where entity resolution helps AML and sanctions review
AML and sanctions workflows can suffer when the same customer or related party appears under multiple spellings, aliases, addresses, or source identifiers. Entity resolution helps expose those connections so reviewers are not limited to one isolated record.
The value is strongest when the match evidence remains visible. Analysts need to understand why records were connected before they make, escalate, or document a decision.
What financial institutions should validate before adoption
Financial institutions should validate match quality, false positives, false negatives, latency, explainability, data freshness, privacy controls, and auditability on their own customer and counterparty data.
They should also decide which workflows use the resolved context, who can override or correct matches, and how changes flow into existing KYC, AML, case-management, and governance processes.
Frequently Asked Questions
- How do financial institutions use entity resolution to meet AML and KYC requirements?
- They use entity resolution to connect fragmented customer and counterparty records, aliases, identifiers, and source-system data into a clearer identity view. That view can support onboarding, screening, monitoring, and investigations, but it does not by itself satisfy AML or KYC obligations.
- What is perpetual KYC?
- Perpetual KYC is an ongoing approach to customer due diligence where customer information and risk context are reviewed as data changes, rather than only at onboarding or at fixed periodic intervals.
- How does entity resolution help with perpetual KYC?
- Entity resolution helps by resolving and assembling new customer data as it arrives, then making the current resolved context available to screening, monitoring, and review workflows at query time.
- Does entity resolution replace KYC screening tools or compliance policies?
- No. Entity resolution is a data layer that can improve the identity context used by KYC and AML workflows. Institutions still need screening tools, governance, documented procedures, legal review, and analyst escalation paths.
- How can entity resolution support sanctions and PEP monitoring?
- It can help connect aliases, spelling variants, changed attributes, and related records so screening workflows see a fuller identity context. Teams still need to validate list sources, thresholds, false-positive handling, and investigation evidence.
Evaluate Tilores on your own data
Use the next step that matches your evaluation stage.
See what resolved entity data does for your business — and your AI.