Most fintech teams do not buy a "compliance stack" in one purchase. They assemble it, one control at a time, usually under deadline pressure from a banking partner, an auditor, or a regulator. The result is often a set of tools that each work in isolation but never quite talk to each other. This guide maps the four layers that actually matter, KYC, KYT, regulatory watch, and reporting, and shows how they connect into a system rather than a pile.
The four layers, in plain terms
Think of compliance as a pipeline that follows a customer and their money from onboarding to exit.
- KYC (Know Your Customer): who is this person or entity, and are they allowed to use your service? Identity verification, sanctions and PEP screening, beneficial ownership, and risk classification live here.
- KYT (Know Your Transaction): what is the money doing? For crypto operators this means on-chain analytics, address risk scoring, exposure to mixers or sanctioned wallets, and travel-rule data on transfers.
- Regulatory watch: what are the rules, and what changed this week? This is the horizon-scanning layer that keeps the other three current.
- Reporting: what do you have to tell whom, and can you prove it? Suspicious activity reports, transaction reporting, audit trails, and evidence for supervisors.
Each layer answers a different question, and a gap in one tends to surface as a finding in the others.
KYC: the front door
KYC is where onboarding friction and financial-crime risk are traded off. The core components are identity verification, screening against sanctions and politically exposed person lists, and a documented risk rating that drives how much monitoring a customer gets afterwards.
The common failure is treating KYC as a one-time gate. Real programs re-screen continuously, because sanctions lists change and a low-risk customer in January can become high-risk by June. A good KYC layer writes its risk rating somewhere the transaction-monitoring layer can read it. Onboarding and monitoring are two ends of one file, not two products.
KYT: following the money on-chain
For anyone touching crypto, KYT is the layer regulators now scrutinise most. In the EU, the recast Transfer of Funds Regulation extended the "travel rule" to crypto-asset service providers, so originator and beneficiary information must accompany transfers regardless of amount, with no de minimis threshold for crypto. This applied from 30 December 2024, alongside the crypto-asset service provider regime under MiCA.
Practically, KYT means:
- Scoring the counterparty address before and after a transaction, not just at signup.
- Detecting exposure to sanctioned entities, darknet markets, mixers, and known theft addresses.
- Keeping a monitored list of addresses tied to your own customers, so a later change in an address's risk profile raises an alert rather than sitting unnoticed.
This is continuous surveillance, not a lookup. An address that is clean today can receive tainted funds tomorrow, and your obligation to notice does not expire at onboarding. Seqlense Monitoring covers this job: ongoing on-chain surveillance of the addresses you care about, with risk scoring and alerts when exposure shifts.
Regulatory watch: the layer everyone underfunds
KYC and KYT controls are only correct relative to the rules in force. Those rules move constantly, and in Europe they move across dozens of authorities at once: ESMA and the EBA at Union level, plus national supervisors such as AMF, ACPR, BaFin, CSSF, FINMA, CNMV, and the data-protection authorities like CNIL and the EDPB when personal data is in scope.
Manual watch does not scale here. A mid-sized fintech operating across three or four member states faces guidance, consultations, opinions, and sanctions from a moving set of regulators, published in several languages. Miss one consultation and your onboarding logic can be out of date months before you notice.
This is where a structured regulatory-watch tool earns its place. Seqlense Doc tracks around 85 European regulators and lets you filter the flow with a query language, SEQQL. For a crypto desk, a standing query like doctype:guidance source:ESMA or doctype:sanction turns a firehose into a short, relevant reading list. The point is not to read everything; it is to never miss the item that changes a control you rely on.
Reporting: proving you did the work
Reporting is where the first three layers pay off or fall apart. It has two faces: the mandatory filings (suspicious activity reports, transaction reporting, prudential returns) and the evidentiary trail you produce for auditors and supervisors on request.
The quiet requirement underneath both is traceability. When a supervisor asks why you onboarded a customer, why you cleared a transaction, or why you did not file, you need to reconstruct the decision with the data and the rule as they stood at that moment. That is only possible if KYC ratings, KYT alerts, and the regulatory context are all timestamped and linked, rather than living in separate tools with separate clocks.
Making it one system
The difference between a stack and a pile is the connections between layers. A workable model looks like this:
| Layer | Core question | Feeds into |
|---|---|---|
| KYC | Who is this? | Risk rating for KYT |
| KYT | What is the money doing? | Alerts for reporting |
| Regulatory watch | What are the rules now? | Thresholds and logic for KYC and KYT |
| Reporting | What must we prove? | Evidence back to supervisors |
Read top to bottom, regulatory watch is not a side activity. It sets the parameters the other three obey, which is exactly why it should not be the layer you run off a shared inbox and good intentions.
You do not need a single vendor for all of this. What you need is for each layer to hand clean, timestamped output to the next, so that when the audit comes, the story reconstructs itself.