Identity verification confirms a person is who they claim to be. KYC is broader: it requires understanding why that person wants a relationship with your institution, assessing the risk they carry, and watching that risk over time. Fintechs routinely buy the first and report the second to their regulator, and the gap between the two is where most customer identity verification programmes are quietly non-compliant.
What is identity verification?
Identity verification is the step that checks a claimed identity against a reliable source: a government-issued ID, a selfie matched to a photo, a database lookup confirming a name and date of birth belong to a real, existing person.
That's a real, necessary control, and it's gotten genuinely good. Document capture, liveness detection, and database cross-checks can confirm identity in seconds, across borders, with less friction than a paper form ever offered. None of that is in dispute. The problem is what identity verification, on its own, doesn't tell you. It confirms who opened the account. It says nothing about why they opened it, what they intend to do with it, or whether their activity six months from now still matches the risk profile they started with.
What is KYC, and how is it different?
KYC, know your customer, is the full customer due diligence obligation: identify and verify the customer, identify the beneficial owner, understand the purpose and intended nature of the relationship, and monitor it on an ongoing basis.
Identity verification is the first of those four elements. It's necessary, and it's the easiest to automate, which is exactly why it's the one that gets sold as if it were the whole obligation. A vendor demo that nails document capture and liveness detection looks like a finished KYC programme to a buyer under deadline pressure. It isn't. The other three elements, beneficial ownership, purpose and risk understanding, ongoing monitoring, don't show up in that demo at all, because they aren't a one-time check. They're a standing obligation that has to run for the life of the relationship.
What does the regulatory text actually require?
FATF Recommendation 10, the global standard behind every national KYC regime, lists four required elements, and identity verification is only the first one.
The other three are explicit in the standard: identifying the beneficial owner and verifying their identity on a risk-sensitive basis, understanding and obtaining information on the purpose and intended nature of the business relationship, and conducting ongoing due diligence with continuous scrutiny of transactions against the institution's knowledge of the customer. The Philippines' own Manual of Regulations for Banks, Section 921, mirrors this framework directly, requiring covered institutions to understand and obtain information on a relationship's purpose, and to conduct ongoing due diligence and transaction scrutiny throughout its course, not only at onboarding. The AMLA's implementing rules add ongoing monitoring as its own standing rule, separate from the identification step entirely. None of this is ambiguous. It's written down, in the same regulation fintechs cite when they say they're KYC-compliant.
Why do fintechs conflate the two?
Because identity verification is the part that's easy to buy, easy to demo, and easy to point to when a regulator asks whether onboarding controls exist. The other three elements are harder to show off and harder to build.
A slick onboarding flow with real-time document scanning and a five-second liveness check is a genuinely impressive product experience, and procurement teams evaluating vendors under time pressure understandably weight what they can see in a demo. Beneficial ownership determination, purpose-of-relationship documentation, and ongoing monitoring are less visually compelling and considerably harder to implement well. They require calibrated risk logic, not just a camera and an ID-matching model. The result is a common and quietly dangerous pattern: an institution buys identity verification, integrates it, and reports to its board and its regulator that it has “implemented KYC.” Technically, it's implemented a quarter of it.
What does the identity verification process actually need to feed into?
A compliant identity verification process doesn't end when a document is matched and a face is confirmed. It needs to hand off cleanly into risk classification, name screening, and a case record that persists for the life of the relationship.
Treated as a standalone checkbox, identity verification produces a confirmed name and nothing else, an output going nowhere. Treated as the front door of a full KYC process, that same confirmed identity becomes the input to a risk score, a sanctions and PEP screening pass, and a case file that gets revisited every time the customer's behaviour, ownership, or transaction pattern changes. The verification step is identical in both scenarios. What differs entirely is what happens to its output afterward, and that's the part a document-scanning tool was never built to do.
What should identity verification software actually do?
Identity verification software should treat a confirmed identity as the start of an obligation, not the end of one, by feeding directly into ongoing risk monitoring rather than closing the file.
Evaluated on its own, identity verification software is graded on match accuracy, liveness detection quality, and document coverage across jurisdictions, all fair, all necessary. But a buyer building a genuine KYC programme needs to ask a harder question before signing: once this tool confirms an identity, where does that confirmation go? Does it flow into a screening and risk engine that keeps watching the relationship, or does it stop at a green checkmark and a stored PDF? The second answer is common. It's also the reason so many institutions can point to a KYC vendor contract and still fail an examination on the other three elements of the same regulation.
Where Name Screening and Case Management make the distinction concrete
Identity verification confirms a name. Name Screening checks whether that confirmed name, and any beneficial owner behind it, appears on a sanctions, PEP, or adverse media list, on an ongoing basis as those lists change, not only once at onboarding. Case Management holds the purpose-of-relationship documentation, the risk classification, and the full history of that customer's file as one connected record, so the “understand the relationship” and “monitor it over time” elements of KYC have an actual home instead of living in someone's memory or a separate spreadsheet.
Put together, that's the difference this piece has been describing throughout: identity verification tells you who opened the account. Name Screening and Case Management are what make the rest of KYC, the part regulators actually examine, real and demonstrable rather than assumed.