Written by:
Last Published:
21 September 2026
•
You've built the feature. It works. Then compliance says no. Not because the logic is broken, but because you missed a regulatory layer somewhere. Maybe it's KYC verification on signup. Maybe it's transaction monitoring. Maybe it's GDPR data retention. But the feature stalls and the launch delays. You're back in the sprint backlog.
Here's the uncomfortable truth: compliance isn't the compliance team's job alone. It's yours. As a developer or CTO building fintech, regulatory requirements are architectural requirements. Miss them, and you're not just delaying launch. You're risking fines, license rejection, or worse.
At Imaginary Cloud, we've spent years building fintech systems across payment platforms, lending apps, and trading engines. We've delivered solutions for major financial institutions, regional banks, and specialised investment platforms. What we've learned is simple: compliance is easier when it's baked in from the start.
This guide is for you. Developers, CTOs, compliance engineers, actually anyone building regulated financial software. We'll cover the regulatory landscape, the technical implementation patterns, the common pitfalls, and the practical steps to get compliant code into production.
Fintech compliance means building software that satisfies regulatory requirements for anti-money laundering (AML), know-your-customer (KYC), data protection, and jurisdiction-specific rules. Think of it like this: if a bank building a locked apartment complex needs the locks (encryption), the keycard system (authentication), and a security log (audit trail), fintech is the same. Rules exist. Code must enforce them. Oversight must verify.
Why should you care? Because compliance isn't optional, and it's not a phase you can skip. It's woven into:
Miss compliance, and you're not just breaking rules. You're building technical debt that gets exponentially more expensive to fix later. At Imaginary Cloud, we've seen teams retrofit compliance into systems designed without it. It's slow and usually costs 3 to 5x more than building it right the first time.
Compliance rules differ wildly by jurisdiction. There's no "one global standard." If you're launching internationally (or even thinking about it), you need to know the landscape.
Three regulatory pillars shape fintech development everywhere: anti-money laundering (AML), know-your-customer (KYC), and data protection. On top sit jurisdiction-specific rules - and they vary. Here's what you need to know:
The Financial Crimes Enforcement Network (FinCEN) governs Money Services Businesses (MSBs). If you're handling money transfers, payouts, or stored value, you likely need FinCEN registration.
1. Core obligations:
2. 2026 update: FinCEN's focus has tightened on de-risking. Banks are dropping customers more aggressively, so fintech acting as a middle layer must have airtight compliance. One missed SAR filing and your banking relationships are at risk.
Europe's regulatory stack is dense. PSD2 (Payment Services Directive 2) mandates open banking and strong authentication. GDPR demands data minimisation and privacy by design. MiFID II applies if you're offering investment services.
1. PSD2 (Payment Services):
2. 2026 update: PSD2 Phase 2 (October 2024 baseline) now requires tighter SCA enforcement. Banks have raised the bar. Strong auth isn't optional anymore.
3. GDPR (Data Protection):
4. MiFID II (Investment Services):
After Brexit, the UK's Financial Conduct Authority (FCA) sets its own rules. UK fintech faces regulatory divergence from the EU now. You can't assume GDPR compliance equals FCA compliance.
1. Key FCA rules:
Asia-Pacific is a patchwork. Singapore has MAS (Monetary Authority). Hong Kong has SFC (Securities and Futures Commission). Australia has ASIC. India has RBI. Each has different AML/CFT (Counter-Financing of Terrorism) rules per FATF guidelines, license requirements, and data localisation mandates.
1. Common thread: Most APAC countries require:
2. Quick win: If you're expanding to APAC, hire a local compliance consultant before writing code. Data localisation requirements alone can force architectural changes.
This is where theory meets code. Here's how AML and KYC work, what developers need to build, and what mistakes to avoid.
KYC (Know Your Customer) verifies who your customer is before you onboard them. AML (Anti-Money Laundering) watches what they do after onboarding and flags suspicious patterns. For developers: KYC is a gating function on signup. AML is a continuous monitoring engine in your transaction pipeline.
KYC flow typically looks like this:
From an architecture standpoint:
At Imaginary Cloud, we've built KYC flows for cross-border payment platforms, and here's what works:
POST /kyc/start
- Create KYC session
- Return redirect URL to verification provider
- Store session ID and provider reference
Webhook: verification_complete
- Check result (approved/rejected/manual_review)
- Update user status
- Trigger downstream actions (enable trading, allow transfers)
Common mistake: Hardcoding risk thresholds. You might say "all US customers are low-risk." That's wrong. Geography is one signal. A US customer sending $50k daily to sanctioned countries is high-risk, regardless of document type. Risk scoring should be rules-based and learned, not hardcoded.
AML watches the stream of transactions and flags outliers.
AML typically operates in three layers:
From an architecture standpoint:
At Imaginary Cloud, we've implemented AML monitoring for payment platforms, and here's the pattern that works:
POST /transfer/send
- Sanitise inputs (amount, recipient, purpose)
- Run sanctions screening (sync, fast-path if cached)
- Run transaction monitoring rules
- If score < threshold: Approve immediately
- If score >= threshold: Hold, escalate to review queue
- Log all signals (for SAR filing later, if needed)
- Return to user: "Processing..." or "Approved"
Common mistake: Approving transactions too quickly without escalation paths. You run a rules engine. It flags 5% of transactions as suspicious. If all 5% auto-reject, customers get frustrated ("Why was I blocked?"). If all auto-approve, you're not mitigating risk. Best practice: Auto-approve clear cases (score < 20). Auto-reject high-risk (score > 80). Escalate the middle (20 to 80) to a human review queue.
Fintech data is gold. Customer PII, financial history, transaction metadata - all of it sensitive. Regulators care deeply. So should you.
Direct answer: Fintech must encrypt data at rest and in transit, limit who can access it, and let users delete it (even though fintech audit requirements make this hard). GDPR, CCPA, LGPD, and local regulations all demand this.
GDPR applies if you process data of EU residents. Key obligations:
Data Minimisation: Collect only what you need for the stated purpose.
Penalties for Non-Compliance: GDPR violations carry significant financial penalties. Organizations can face fines up to 4% of global revenue under GDPR, making compliance not just a regulatory requirement but a critical business imperative.
Encryption: Data at rest (in databases) and in transit (over networks).
Right to Erasure: Customers can request deletion. You must delete (with exceptions for audit logs).
users table from transactions table. When a user requests deletion, delete their PII but replace it with a hash. Transactions stay for audit, but aren't linked to the person anymore.Data Protection Impact Assessment (DPIA): Document your processing. What data? Why? Who accesses it? How long kept?
Common mistake: Logging sensitive data. A developer logs an API response for debugging. That response includes a customer's SSN. Now SSNs are scattered in log files. Encrypt those logs, or better - don't log sensitive data at all. Log anonymised signals: "KYC verification for user_id 123 returned approved" instead of "KYC for John Doe, SSN 123-45-6789, returned approved."
If you're building a payment platform or offering payment initiation services, PSD2 is your bible.
Direct answer: PSD2 mandates strong authentication and open APIs. If your platform lets customers authorise payments, you need SCA (Strong Customer Authentication). If you're an aggregator pulling data from multiple banks, you need access to standardised open APIs.
SCA means two independent factors of authentication. Not just password and SMS. Something like:
Example: Customer initiates a payment. Password verified? Good. Now: "Confirm with fingerprint or enter your PIN."
Exemptions (PSD2 allows some relaxation):
Dev implication:
PSD2 requires banks to offer read/write APIs so authorised third parties (Account Information Service Providers, Payment Initiation Service Providers) can access/initiate on behalf of customers.
For you as a fintech:
Dev implication:
Compliance isn't a launch day thing. It's continuous. You need monitoring, alerting, and testing.
Direct answer: Set up automated checks for KYC expirations, AML rule triggers, GDPR data inventory, and audit logging. Test your compliance logic the same way you test business logic - unit tests for AML rules, integration tests for KYC workflows.
KYC Expirations:
AML Rules:
GDPR Data Inventory:
Example monitoring setup:
- KYC expiration dashboard: % of users with valid KYC
- AML metrics: Transactions flagged/approved/reviewed per day, avg review time
- GDPR compliance: Data over retention window, unencrypted data, access logs
- SARs filed: Count, reasons, time-to-file
Treat compliance like a feature.
Unit tests for AML rules:
def test_high_velocity_detection():
customer = Customer(daily_average_volume=1000)
transaction = Transaction(amount=5000) # 5x average
result = aml_engine.check(customer, transaction)
assert result.risk_score > 80 # High-risk flag
assert result.reason == "VELOCITY_ANOMALY"Integration tests for KYC workflows:
def test_kyc_flow_end_to_end():
# Create user
user = User.create(email="test@example.com")
# Start KYC
kyc_session = kyc_provider.start_verification(user)
# Simulate approval webhook
kyc_provider.mock_approval(kyc_session.id)
# Check user status updated
user.refresh()
assert user.kyc_status == "approved"
assert user.features_enabled == ["trading", "transfers"]Compliance audit checklists:
Common mistake: Treating compliance tests as optional. "We'll regression test business logic, but compliance... eh, manual QA handles that." Wrong. Compliance bugs are the most expensive. One misconfigured AML rule and you're filing false SARs. Automate.
Outsource. OFAC lists update. Sanctions designations change. Do not build screening in-house. Use a third-party provider (Compliant, Refinitiv, etc.) that maintains fresh lists and has legal liability if they miss a designation.
Pseudonymisation: Delete the link between person and audit record, but keep the record. Example: In an audit log entry {user_id: 123, action: "transfer", amount: 1000}, delete the user record but replace user_id with a hash or random token. Regulators accept this - transaction history is preserved, but the person is anonymised.
No. Implement retry logic. Customer can re-submit documents 2 to 3 times. After that, escalate to support (maybe the document is genuinely hard to verify, or maybe it's fraud - a human should decide). Don't permanently block without escalation.
Risk-based. Low-risk customers: every 3 years. Medium-risk: annually. High-risk: quarterly. Regulatory guidance varies by jurisdiction, but risk-based refreshing is the standard.
Yes, you can store encrypted SSNs. Encryption is acceptable for GDPR and FinCEN. But best practice: store only a hash or token, not the SSN itself. If you need the actual SSN (for wire transfers, for example), request it on-demand from the customer, process it, then discard it. Don't persist.
6 to 7 years in most jurisdictions. US FinCEN requires 5 years minimum. EU and UK often require 6 to 7 years depending on the transaction type. Check your jurisdiction. Also check your payment processors - they might have longer requirements.
Investigate and file a correction memo. Document why you flagged them (rule X triggered). Document why it was a false positive (customer explained purpose, provided proof, etc.). Keep the memo in your file. If a regulator audits, you show: "We flagged, we investigated, we resolved." That's due diligence.
Risk-based. VPN use doesn't auto-trigger a block. But if a customer uses a VPN to mask their geography and match a sanctions rule, that's suspicious. AML rules should incorporate this: "Customer from US, suddenly connecting from Iran via VPN → high-risk." Let human reviewers make the call.
Never tell the customer you filed a SAR. That's illegal ("tipping off"). File it, keep quiet, move on. Internally: document why you filed (rule triggered, thresholds met, etc.). Keep SAR records confidential - don't log them in customer-facing systems.
Treating compliance as a post-launch feature. Teams ship fast, then retrofit compliance. By then, the codebase is a mess, compliance is a hack, and technical debt is astronomical. Build compliance in. It's not slower - it's cheaper.
You've read the rules. You understand the architecture. Now: how do you actually build this?
Step 1: Pick your jurisdiction(s).
Step 2: Audit your current system (if you have one).
Step 3: Integrate third-party services.
Step 4: Implement compliance flows.
Step 5: Test relentlessly.
Step 6: Document and maintain.
Step 7: Launch and monitor.
Compliance isn't a phase. It's not something you bolt on after launch. It's architecture - a set of constraints that shape how you design systems, how you store data, how you test.
Build it right, and it's invisible. Users onboard smoothly. Transactions flow. Regulators inspect your logs and nod. You sleep well.
Build it wrong, and it's your whole roadmap. Retrofitting compliance into a non-compliant system costs 3 to 5x more than building it in. Teams spend quarters rewiring. Launched products get suspended. Investors balk.
Here's your takeaway:
At Imaginary Cloud, we've built dozens of compliant fintech systems. The ones that succeed are the ones that treat compliance as a first-class citizen from day one - not an afterthought. Our experience working on platforms like BNP Paribas, Banco Montepio, and specialized services like TrustPortal has taught us that foundational compliance architecture drives long-term success.
Your regulators are watching. Build well.
Building fintech software that needs to get compliance right the first time? Our team at Imaginary Cloud has shipped compliant systems for banks, payment platforms, and regulated fintechs across Europe and the US. Get in touch to talk through your compliance architecture before you write a line of code.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
