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, and 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 screening is also 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, and then an exchange somewhere upstream re-scores a pool of old transactions, decides a deposit they made many months ago now looks risky, and the account gets frozen 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, which means your system has to expect its own past decisions to be reopened and handle it without punishing the wrong person.
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, because 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.
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.
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.
