Compliance & Regulatory by Design
Compliance is not paperwork wrapped around the product. It is something the product must prove, on demand, with evidence. In a regulated AML business, the question is never "are we compliant?" in general. It is "can we prove it for this specific decision, on this date, to this regulator?" Build so the answer is always yes.
Designing for compliance means the controls a regulation requires are enforced in code, and the evidence it requires is produced automatically. It is not rebuilt under a deadline when an auditor asks. When teams add compliance late, they discover the log they needed was never written, the consent was never recorded, or the decision cannot be explained.
Our obligations are concrete and overlap: AML/KYC rules, GDPR (including special-category biometric data), data residency, and, for automated risk decisions, the EU AI Act. Each one sets controls and evidence requirements. The cheapest way to meet them is to make the compliant path the default path.
Build the controls in
- AlwaysTreat each regulatory requirement that touches your feature as an explicit acceptance criterion, enforced in code and covered by a test.
- DoKnow which rules apply to the data and decisions you are handling (AML/KYC, GDPR, AI Act, residency) before you design, not after.
- DoEnforce data residency by design: regulated EU data is stored and processed in the correct region, not wherever the default puts it.
- DoMake the lawful default the system default: block and escalate on missing checks, consent recorded before processing, and retention enforced automatically.
- ConsiderA data protection or risk impact assessment for features that touch special-category data or automated decisions, done early, while the design can still change.
- NeverShip a feature that processes regulated data in a way you cannot evidence as compliant, or in a region that breaches residency obligations.
Produce evidence automatically
- DoProduce the evidence a regulator would ask for as a by-product of the operation (who, what, when, on what basis), not as a manual reconstruction afterwards.
- DoMake regulated records (KYC, AML, audit, consent, decisions) append-only and tamper-evident, with their own retention rules.
- DoKeep the mapping from requirement to control to evidence visible, so it is clear what proves what when the question comes.
- ConsiderDesigning for the audit before it happens. If you cannot answer "prove this decision was lawful" right now, that is a gap to close now.
- Do notRely on knowledge in someone's head, or on a person being available, to explain a regulated behaviour. The system must speak for itself.
- NeverSuppress, edit, or delete statutory evidence (SARs, alerts, audit, KYC/AML records). Regulated evidence is append-only.
Self-review checklist
- AskWhich regulations touch this feature, and is each one's requirement enforced in code?
- AskIf a regulator asked me to prove this specific decision was lawful, could I, using evidence the system produced itself?
- AskIs regulated data stored and processed in the correct region?
- AskDoes the compliant outcome happen by default, or does it depend on someone doing the right thing?