A real customer tries to sign up and gets frozen at the door because their name resembles someone on a sanctions list. Meanwhile, somewhere else, a bad actor walks straight in through a gap nobody instrumented. Both of those are the same failure, just pointed in opposite directions, and getting the line between them right is most of the actual work of onboarding for a money product.
Here is the plain version. The instant your software lets someone move money, you take on a set of obligations that have nothing to do with your features: you have to know who your customer really is, check them against sanctions and watchlists, and keep watching their behavior over time. None of that is optional and none of it is where the difficulty lives. The difficulty is that every one of those checks can be wrong in two directions, and tuning it so you stop the fraud without rejecting the customer you wanted is the part that takes real judgment.
The fortress is the product, before the product is
Onboarding for a money app is a sequence of gates, and each one is a place to be too strict or too loose. Identity verification confirms the person is who they claim, usually with a document and a liveness check so a photo of a photo does not pass. Sanctions and politically-exposed-person screening checks them against lists that are themselves noisy, full of common names and stale entries. Then monitoring watches what they do afterward, because someone clean at signup can turn risky later.
The thing nobody tells you going in is that the screening lists generate false matches constantly. A system that treats every near-match as a criminal will reject a stream of legitimate people, while a system that waves them through will let real risk inside. The craft is the tuning, and the tuning is specific to your customers, your geographies, and your risk appetite.
The check that comes back a year later
The screening is not a one-time gate, and the cruelest version is retroactive. A customer passes every check at signup and uses the product cleanly for a year. Then an exchange somewhere upstream re-scores a pool of old transactions and decides a deposit made many months ago now looks risky, and the account freezes over money that was clean when it moved.
The customer did nothing. Their balance is simply locked while two compliance teams that have never spoken argue about a transaction neither of them can fully see. That is the scenario your architecture has to expect: its own past decisions being reopened, months later, by someone else's model, and handled without punishing the wrong person.
Laid out, the three gates and their two opposite failure modes look like this.
| Gate | What it checks | Too strict | Too loose |
|---|---|---|---|
| Identity verification | The person is who they claim, using a document plus a liveness check | A real customer cannot finish signup and abandons | A photo of a photo passes as a live person |
| Sanctions and PEP screening | The customer against sanctions and politically-exposed-person lists | A common name hits a stale entry and a legitimate customer is frozen at the door | A genuine match gets waved through as noise |
| Ongoing monitoring | Behaviour after signup, because someone clean at signup can turn risky later | Routine activity floods the queue until nobody reviews it properly | Risk that only appears later is never noticed |
We have built this end of fintech under a real banking regulator, the identity and document and liveness onboarding for a regulated wealth platform with custody integration, where the compliant path and the path a customer will actually finish have to be the same path. The designer on our team who built that flow had the harder half of the problem.
A fortress nobody can get through is not secure, it is just empty.
We have also built onboarding inside a loan-application product reached through a messaging app, where the same obligations had to live inside a conversational flow with document handling and a clean handoff from automation to a human reviewer. When you ride a partner bank for your rails, who holds these obligations gets more complicated, not less, which is part of the embedded-finance decision.
You will have to prove every decision you made
The part that quietly changes your architecture is that compliance is not just about making the right call at onboarding. It is about being able to prove, later, what call you made and why. That means an audit trail that records who was checked, against what, with what result, and when, and it means that audit trail cannot be something your application can quietly edit or skip. The discipline is to make the audit write a property of the system rather than a line of code someone has to remember, written by the database itself, so there is no path through your software that performs a consequential action without leaving the record behind it. A consequential action that cannot be audited should simply not complete. Build it that way and a regulator's question becomes a query. Build it the easy way and it becomes a very bad week.
This gets sharper in regulated corners like consumer lending, where disclosure rules vary by jurisdiction and the claims you make in your own interface are themselves regulated. The engineering does not get you out of the legal work, but the wrong engineering can quietly create legal exposure you did not know you had.
For anything with European exposure, the audit-trail argument now has a countdown attached. The EU's new Anti-Money Laundering Authority became operational in Frankfurt on July 1, 2025 and took over the EU-level mandates from the European Banking Authority on January 1, 2026. The single EU rulebook, the AMLR, applies directly across all member states from July 10, 2027, and the authority begins directly supervising a selected set of high-risk institutions on January 1, 2028. Rules deciding the architecture stops being a design philosophy at that point and becomes a schedule.
What's still standing in 2028
The reason this layer keeps gaining value is that AI is making the attack cheaper. Synthetic identities, convincing fake documents, and automated fraud are all getting easier and more scalable, which means the ability to prove a customer is real, and to prove you checked, is worth more every year rather than less. By 2028 a slick signup screen is something anyone can generate. A signup that is fast for the right people, hard for the wrong ones, and fully defensible to a regulator is not.
FAQ
What is KYC and AML onboarding? The instant your software lets someone move money you take on obligations that have nothing to do with your features: know who the customer really is, check them against sanctions and watchlists, and keep watching their behaviour over time. None of it is optional, and none of it is where the difficulty lives.
What is sanctions and PEP screening? Checking a customer against sanctions and politically-exposed-person lists, which are themselves noisy, full of common names and stale entries. They generate false matches constantly, so a screening result is the start of a judgement rather than a verdict you can act on directly.
Why do KYC checks reject legitimate customers? Because every check can be wrong in two directions. A system that treats every near-match as a criminal rejects a stream of legitimate people, and one that waves them through lets real risk inside. The craft is tuning that line to your customers, your geographies, and your risk appetite.
What is retroactive de-risking? When a customer passes every check at signup, uses the product cleanly for a year, and then an exchange upstream re-scores old transactions and decides a months-old deposit now looks risky. The balance freezes over money that was clean when it moved, so your system has to expect its own past decisions to be reopened.
What audit trail does AML compliance require? One that records who was checked, against what, with what result, and when, and that your application cannot quietly edit or skip. Make the audit write a property of the system, written by the database itself, so no path performs a consequential action without leaving the record behind it.
Why is KYC getting harder rather than easier? Because AI is making the attack cheaper. Synthetic identities, convincing fake documents, and automated fraud are all getting easier and more scalable, which means the ability to prove a customer is real, and to prove that you checked, is worth more every year rather than less.
What 2muchcoffee covers
We build and harden the onboarding and compliance layer for money-moving products, the identity and liveness, the screening, the monitoring, and the audit trail that makes all of it provable, designed so the compliant path is also the one users finish. If you are about to let people move money and the words "sanctions screening" just turned into a real engineering question, that is the conversation to have early. The plain way in is the AI and engineering work we do.
One concrete action
Pick one onboarding decision your system will make, an identity match or a sanctions hit, and write down exactly what evidence you could produce six months later to defend it: what you checked, what came back, who decided, and when. If you cannot answer that cleanly, you have found the part of building fintech software to build first, because in this corner the record of the decision is as load-bearing as the decision.
