Backend Engineering in Fintech: Key Considerations for Regulated Environments

1. Introduction - The Fintech Engineering Context

Building backend systems for financial services is fundamentally different from building a typical SaaS product. The stakes are higher, the rules are stricter, and the margin for error is essentially zero. This isn’t hyperbole - it’s the reality of working in an industry where regulatory fines can exceed your annual revenue and a single bug can wipe out customer trust permanently.

1.1 Who This Is For

This guide is for backend engineers working in or moving into regulated financial services:

Banks and challenger-banks - that hold deposits and operate under banking licenses. You’re dealing with the full weight of banking regulation, capital requirements, and central bank oversight.

Payment service providers (PSPs) and payment facilitators - that move money between parties. You might be handling card payments, bank transfers, or digital wallets - each with its own regulatory framework.

Lending platforms and Buy Now Pay Later (BNPL) providers - that extend credit. You’re subject to consumer credit regulations, fair lending laws, and potentially capital adequacy requirements.

Exchanges and brokerages - handling securities, forex, or crypto. You’re operating market infrastructure with real-time settlement, complex regulatory reporting, and significant operational risk.

Custody providers and wallet services - that hold assets on behalf of customers. You’re responsible for safeguarding value, which comes with strict security and insurance requirements.

Embedded finance platforms - that enable other companies to offer financial services. You’re often responsible for compliance on behalf of your customers, which amplifies the regulatory complexity.

1.2 Why Should I Care

Building financial systems carries different stakes than typical software engineering.

Company liability. Your mistakes can take down the entire organization. The multiplicative risk problem (see below) means a small error rate can exceed your entire margin. Companies have gone under from single engineering failures.

Personal liability. Engineers working on financial systems have a professional duty of care. Like doctors, lawyers, and architects, you can be held personally liable for negligence. Courts and regulators expect you to understand regulatory requirements when handling other people’s money. “I didn’t know” isn’t a defense. Career risk compounds this - compliance failures follow you, and the financial services industry is smaller than you think.

Criminal liability. Higher regulation means more potential for committing offences that seem innocent on their face. Circumventing AML controls, mishandling customer data, or failing to report suspicious activity can carry criminal penalties. Senior engineers have been personally named in enforcement actions.

Higher earning potential. The flip side: engineers who understand how to build compliant, auditable, secure systems are genuinely valuable. The specialized skillset commands premium compensation. Fintech pays more because the stakes are higher.

Understanding these constraints isn’t optional - it’s the baseline for working in the industry.

1.3 Why Fintech is Fundamentally Different from Generic SaaS

1. The multiplicative risk problem

In most SaaS companies, if you have a bug, you might lose some user data or cause downtime. That’s bad, but it’s containable. In fintech, you’re typically earning 1-3% in fees but you’re actually moving 100% of the money. A payment processor charging 2.9% per transaction is still responsible for the full transaction amount. If you move £10M monthly and earn £200K in fees, a bug that loses 1% of transactions costs you £100K - half your revenue - plus regulatory penalties and reputation damage. The financial exposure is multiplicative, not proportional to your margins.

2. Integration with the wider financial system

Your system isn’t self-contained. You’re plugging into banking rails, card networks, exchanges, and regulatory reporting systems. When something breaks, the consequences ripple outward. A bug in your system might cause failed transactions at a major bank, incorrect reporting to a financial regulator, or disrupted trading on an exchange. You’re not just responsible to your users - you’re responsible to the entire financial ecosystem you’re connected to.

3. Irreversibility and finality

In most software, you can roll back a database transaction, restore from a backup, or apologize and credit the user some goodwill. In finance, once money moves through settlement systems, it’s final. You can’t just DELETE FROM transactions WHERE mistake = true. Many corrections require a compensating transaction, regulatory approval, and extensive documentation. The immutability requirement isn’t a design choice - it’s a legal obligation.

4. The compliance-velocity tension

Every fintech startup begins with good intentions: “We’ll move fast and iterate.” Then they encounter their first regulatory audit. Suddenly, every code deployment needs a change control ticket. Every database schema change needs a migration plan that’s reviewed by compliance. Every new feature needs a legal review and potentially a regulatory filing. The “move fast and break things” mentality doesn’t just slow down in fintech - it becomes actively dangerous. Companies that try to maintain startup velocity while ignoring compliance end up either shut down by regulators or spending years and millions in remediation.

5. Trust as the core product

When users sign up for your SaaS product, they’re trusting you with their data. When they use your fintech product, they’re trusting you with their money. The psychological difference is massive. A data breach at a social media company causes outrage and maybe some churn. A security breach at a fintech company causes immediate customer exodus, regulatory intervention, potentially permanent reputation damage, and possible prohibition orders banning individuals from performing controlled functions in regulated firms. Trust takes years to build and seconds to destroy, and in finance, you don’t get second chances.

1.4 Regulatory Landscape Overview (UK/EU Focus)

I cover regulations in more depth in Fintech Regulations Decoded, but here’s a quick overview of what you’ll encounter.

• GDPR (General Data Protection Regulation) - applies to any company handling personal data of EU residents, regardless of where the company is located. The requirements include PII minimization, right to erasure, data residency, and Data Processing Impact Assessments for high-risk processing. The fines are eye-watering: up to €20M or 4% of global annual revenue, whichever is higher. The UK has its own version post-Brexit (UK GDPR) that’s substantially similar.

• AML/KYC regulations (Anti-Money Laundering / Know Your Customer) - apply to essentially all regulated financial services. You must verify customer identities, monitor transactions for suspicious activity, and report to financial intelligence units. In the UK, this means compliance with the Money Laundering Regulations 2017 and reporting to the National Crime Agency.

• Licensing regimes - before you can offer financial services, you typically need authorization. E-Money Institution (EMI) licenses for payment services and e-wallets, Payment Institution (PI) licenses for payment processing, banking licenses for deposit-taking and lending, investment firm authorization for securities. Each comes with capital requirements, governance rules, and ongoing supervision. The license you need depends on what you’re doing - and operating without one is a criminal offence.

• PCI DSS (Payment Card Industry Data Security Standard) - applies to anyone storing, processing, or transmitting cardholder data. It’s not government regulation - it’s a private industry standard enforced by card networks. But the consequences of non-compliance are severe: you lose the ability to process card payments. PCI DSS requires network segmentation, encryption, quarterly vulnerability scans, annual penetration testing, and comprehensive audit logging. There are different compliance levels based on transaction volume. My usual recommendation is to minimize the PCI scope whenever possible, and plan well in advance if full compliance is needed.

• PSD2 (Payment Services Directive 2) and Strong Customer Authentication - apply to payment services in the EU/EEA. PSD2 requires Strong Customer Authentication (SCA) for electronic payments - that means two-factor authentication for any transaction over €30. It also mandates open banking APIs. The technical standards specify exactly how authentication must work: two of three factors (knowledge, possession, inherence) with dynamic linking to the transaction.

• MiFID II (Markets in Financial Instruments Directive II) - applies to investment firms and trading venues in the EU. It requires transaction reporting (every trade must be reported to regulators), best execution, and investor protection measures.

• MiCA (Markets in Crypto-Assets Regulation) - is the EU’s new framework for crypto assets, fully effective in 2025. It creates licensing requirements for crypto exchanges, wallet providers, and stablecoin issuers.

• EU Travel Rule (Transfer of Funds Regulation) - requires crypto asset service providers (and traditional payment providers) to collect and transmit sender/receiver information with transfers. Similar to SWIFT messaging requirements for bank wires, but now applied to crypto. You need to know who’s on both ends of a transaction and share that data with the counterparty provider.

1.5 A Note on Core Banking Ledgers

Any fintech responsible for managing money will eventually need a ledger - the authoritative record of what happened to every penny. When disputes arise, regulators audit, or something goes wrong, the ledger is where you prove your case. It must be immutable, use precise decimal math, maintain audit trails, reconcile constantly, and remain available 24/7.

Building a production-grade banking ledger is a serious undertaking that combines accounting, software engineering, compliance, and operational expertise. It deserves its own detailed treatment. For this article, I focus on the broader backend engineering considerations that surround the ledger.

2. Currency Handling & Decimal Precision

When you’re responsible for other people’s money, every fraction of a penny matters. Calculations need to be exact, reproducible, and auditable. When a customer disputes a charge or a regulator audits your books, you need to reproduce the exact calculation that produced a specific result.

1. Never use floating-point numbers for money.

Open a Python REPL and type 0.1 + 0.2. You get 0.30000000000000004. That tiny error compounds - a payment processor handling millions transactions per day could accumulate thousands of dollars in unexplained variance from floating-point errors alone.

Use proper decimal types: DECIMAL/NUMERIC in databases, BigDecimal in Java, decimal.Decimal in Python, shopspring/decimal in Go (or other decimal packages). Alternatively, represent amounts as integer minor units (cents, pence, satoshis) and convert to decimals only at display boundaries.

2. Handle currency precision correctly.

Different currencies have different decimal places. EUR and USD use 2. Japanese Yen uses 0. Bahraini Dinar uses 3. Bitcoin uses 8. Ethereum uses 18. Spoiler alert - they do change over time. Hardcoding assumptions will break.

Maintain a currency metadata table with ISO-4217 codes, decimal places, and rounding rules. Make sure all amounts are properly sanitized on input and output according to specific currency rules.

3. Document and implement a rounding strategy.

When you split £10.00 three ways, you get £3.33 + £3.33 + £3.34. That extra penny has to go somewhere. If you always give it to the merchant, you’re systematically overcharging customers - regulators call this “penny skimming.”

Different situations call for different rounding strategies: Banker’s rounding (HALF_EVEN) is statistically unbiased over many transactions - standard for most calculations. Round half up (HALF_UP) is what most people expect from school maths. Round towards customer (floor for charges, ceiling for payouts) when regulations require favouring the customer. Truncation for tax calculations where regulations specify it.

For things like yield accumulation on interest-bearing accounts, track the fractional amounts separately and only round when actually paying out. Never discard sub-cent amounts silently - either distribute residuals fairly across recipients or maintain a residual account that gets reconciled.

4. Store FX conversions with full context.

For foreign exchange, store the original amount, converted amount, rate used, and timestamp. You need to reproduce historical conversions exactly. Never reuse rates across different time periods - store validity windows.

5. Test with property-based testing.

Verify invariants: sum of splits equals original, rounding is deterministic, currency conversions are reversible within tolerance.

3. Idempotency & Preventing Duplicate Execution

Network failures are the norm. A client sends a payment request, your server processes it successfully, but the response gets lost in a timeout. The client retries. Now you risk processing the payment twice.

User behavior amplifies this: double-clicks, mobile app retries on network errors, browser back buttons resubmitting forms. Every scenario can cause duplicate requests.

Strategies to prevent duplicates:

• Idempotency keys - require clients to provide a unique identifier (UUID/ULID) with every state-changing operation. Store the key, request, and result in your database. On retry, return the cached result instead of re-executing. Scope keys per operation type and set appropriate TTLs (24-72 hours catches legitimate retries without storing infinite history).

• Deterministic keys from business properties - for systems that don’t support idempotency keys (legacy banking systems, some webhooks), generate keys from natural business properties: e.g. hash of (from_account + to_account + amount + currency + date).

• Database constraints - add unique constraints on natural business keys as defense-in-depth. Even if idempotency logic fails, the database won’t allow duplicate transfers.

• Outbox pattern - for reliable event publishing, write the state change and outbox entry in the same transaction, then have a separate worker publish events from the outbox. This ensures exactly-once-effect semantics across your system and external integrations.

4. Guaranteed Execution

Idempotency prevents duplicates, but doesn’t ensure execution happens. Consider card blocking: regulators require that customers can report a card stolen and the company must render it immediately unusable. You can’t return “service unavailable, try again later” - the card must be blocked. But what if the agent clicks “Block Card,” the API returns 200, and due to a database deadlock the block never commits? The card continues working while the customer assumes it’s safe.

Critical safety operations must complete reliably: card blocks, account freezes, AML alerts. These can’t be “eventually maybe” operations.

One approach: Command-Query Responsibility Segregation (CQRS). Validate the command synchronously (authentication, authorization, business rules). If valid, persist it to a durable queue or database. Return 202 Accepted immediately. Background workers execute commands with automatic retries.

Make command execution idempotent so retries are safe. Use exponential backoff with jitter for transient failures. After max attempts, move to a dead letter queue for manual investigation. Alert ops when commands fail.

For complex workflows with compensation logic (multi-step transfers with rollback), consider saga orchestrators like Temporal or Camunda.

5. Time, Cut-Offs, Calendars & “As-Of” Accounting

Financial systems have a complicated relationship with time. It’s not enough to know when something happened - you need to know when it was booked, when it settled, when it was valued, and what the business date was.

Key considerations:

• Settlement is not instant. UK Faster Payments settle within hours, BACS takes 3 business days, SEPA is T+1, international wires can take days.

• Cut-off times determine processing date. Most payment rails cut off between 2-4pm local time. Submit after cutoff and settlement starts the next business day.

• Business calendars vary by region. Payment rails don’t operate on weekends or public holidays. UK banks close on Boxing Day, European banks might not.

• Transactions have multiple dates. A transaction might occur Monday but post Tuesday. You need: transaction date (when it happened), value date (when money moves), and booking date (when it hit the ledger).

• Interest uses day count conventions. Actual/365, Actual/360, 30/360, etc. The specific formula matters for regulatory compliance.

• Regulators require “as-of” reporting. “What were your outstanding loans as of end-of-quarter?” means reconstructing historical state exactly.

Implementation approaches:

• Store timestamps in UTC, but maintain separate fields for business date concepts (processed_at, settled_at, etc.).

• Maintain holiday calendars yourself or use third-party services for business day calculations.

• Use monotonic sequences or lexicographically sortable identifiers (UUIDv6, UUIDv7, ULIDs) for ordering - wall-clock timestamps can go backwards due to NTP adjustments.

• Never delete or update historical records - only append. This enables “as-of” queries.

6. Transaction Immutability & Auditability

Scenario: a transaction was incorrectly recorded as settled. Someone runs an UPDATE to change its status to cancelled. Problem solved - except the account balance was calculated from the original settled status and wasn’t recalculated. Now the ledger doesn’t balance, reconciliation breaks, and you can’t explain the discrepancy to auditors because the original record is gone.

Financial records must be retained for 7+ years in most jurisdictions (UK is 6 years for tax, 7+ for AML). Records must be tamper-evident and complete. Every debit should have a corresponding credit. Breaking this invariant makes your entire ledger suspect.

Recommendations:

• Consider using a write-ahead transaction log - append-only by design, enables reconstruction of state at any point.

• Avoid deleting financial records. Consider archiving or soft-deleting by changing status instead. Status changes are valid - the key is preserving history of what happened.

• For corrections, create new transactions referencing the original rather than modifying the original.

• Consider removing UPDATE/DELETE grants on core financial tables at the database level. Use triggers to block attempts if necessary.

• Worth recording on each transaction: when it happened (created_at in UTC), who or what initiated it (user ID or service name), whether it was automated or user-initiated.

• For non-repudiation, use strong authentication: mTLS for service-to-service, OAuth/OIDC for user operations, API signatures for webhooks. Store authentication context with transactions.

As mentioned earlier, transaction recording typically happens in the ledger, which comes with its own set of considerations around double-entry accounting, balance calculations, and state management. I’ll cover core banking ledger design in a separate article.

7. Tamper-Evident Audit Logging

Logs are your source of truth for incident investigation, regulatory audits, and dispute resolution. SOX requires audit trails for financial operations, GDPR requires logs of PII access, PSD2 requires fraud monitoring. When a customer claims “I didn’t make that transfer” - your logs must prove otherwise.

What to log:

• Every financial operation (transfers, payments, trades)
• All access to PII
• Configuration changes (fee tables, risk parameters)
• Authentication events (login, MFA, failures)
• Authorization decisions (granted/denied with reason)
• Administrative actions (account blocks, manual adjustments)

Implementation considerations:

• Make logs tamper-evident: hash chains (each entry includes hash of previous), WORM storage (S3 Object Lock), or third-party aggregation you can’t modify.

• Use structured JSON with correlation IDs flowing through all services for end-to-end tracing.

• Retention schedules: financial logs 7+ years, PII access logs 3 years, system logs 90 days to 1 year.

• Never log secrets or raw PII. Log user:12345 not [email protected]. Truncate card numbers to first6+last4.

• Implement legal holds: when litigation starts, tag relevant logs and exempt from auto-deletion.

8. Reconciliation - Internal & External

If your database says you have £1M but your bank account has £950K, one of you is wrong.

Your ledger must match reality. Regulators require regular reconciliation as part of operational resilience. Better to discover a £10K variance during daily reconciliation than a €1.9B gap during annual audit - Wirecard’s auditors couldn’t verify cash balances in 2020, and the company filed for insolvency days later.

Internal reconciliation:

• Three-way matching: compare subledgers (customer balances, accounts payable) against general ledger against source systems. Run daily or more frequently.

• Set tolerance thresholds. Small variances (<£1) might be acceptable rounding. Larger variances need immediate investigation.

• End-of-day balancing: all debits must equal all credits, down to the penny. If it doesn’t balance, block EOD close until resolved.

External reconciliation:

• Match your records against bank statements, payment processor reports, card network clearing files, exchange trade

• confirmations, custodian statements.

• Common challenges: timing differences, fee discrepancies, FX rate differences, missing transactions.

• Automate the pipeline: fetch external data, normalize formats, match by reference ID or amount+date, classify variances, alert on exceptions.

9. Data Privacy & GDPR

GDPR requires you to protect personal data - collect only what you need, store it securely, control who can access it. British Airways paid £20M after inadequate security led to 400,000 customers’ payment details being exposed - reduced from an initial £183M. GDPR penalties can reach €20M or 4% of global annual revenue.

But protecting data isn’t enough. You also need to delete it when customers ask - the right to be forgotten. This creates a genuine tension for fintech: financial regulations require you to retain transaction records for 7+ years, but GDPR says customers can demand deletion. You need to satisfy both.

Cross-border data flows add another layer. Schrems II ruling by the CJEU (Court of Justice of the European Union) invalidated the EU-U.S. Privacy Shield, so EU personal data generally needs to stay in the EU unless you have appropriate safeguards in place.

Key considerations:

• PII minimization - only collect what you legally need. Challenge product requirements.

• Never log PII - one of the most common sources of GDPR headaches. Log user_id=abc123 not name=John Doe.

• Data residency - use EU-only cloud regions for EU customers.

• Pseudonymization - replace PII with pseudonyms in analytics. Tokenization for card numbers.

• DPIAs - Data Protection Impact Assessments (DPIAs) are required for high-risk processing. Document what, why, how long, who accesses, security measures.

• Lawful basis per field - GDPR requires a legal justification for each piece of data you collect. Document why you need each field: name and email might be necessary to fulfil the contract, AML records are a legal obligation, fraud detection signals could fall under legitimate interest, marketing requires explicit consent. Different bases have different deletion rules - consent can be withdrawn anytime, legal obligations have fixed retention periods.

• Automated retention - define per data type, automate deletion. Legal holds override.

10. Security Architecture & Access Control

Fintech security architecture is fundamentally defensive - you’re trying to limit blast radius. This means protecting against external threats (attackers, breaches), but equally against insider threats: rogue employees, negligent staff, or compromised credentials. Even small fintechs move big money. You might earn 1% but you’re custodian of 100% of customer funds and their PII.

Some examples of what goes wrong: Equifax (2017) - 147M records exposed via unpatched Apache Struts, $1.4B+ in settlements. Capital One (2019) - 100M records via misconfigured S3, $80M fine. JP Morgan Chase - banker sold customer PII and PINs to criminals for cash. FinWise Bank (2024) - 689K records exposed by former employee, took over a year to detect.

This isn’t meant to be comprehensive security guidance - that’s a book, not a blog post. But here are practices fintechs tend to adopt more eagerly than companies where breach repercussions are lower:

• Network segmentation - web tier can’t reach databases directly, application tier can’t access the card vault. Limits what an attacker can reach from any given foothold.

• Service mesh with mTLS - a fairly straightforward way to enforce fine-grained authorization at the network level. Services can only call specific paths on specific other services, preventing rogue or compromised deployments from accessing endpoints they shouldn’t. Combines identity (client certificates) with path-based access control.

• Least privilege and time-bound access - admin access that expires after a few hours, JIT (just-in-time) access requests rather than standing permissions.

• PCI DSS scoping - isolating the Cardholder Data Environment in a separate VPC and tokenizing card data immediately means most of your system never touches sensitive card data. Smaller scope, lower compliance cost.

• Encryption requirements - know what data needs encryption and what type. PANs require HSM-based key storage, other sensitive data may have different requirements.

• Maker-checker workflows - one person initiates a transaction, a different person approves it before execution. Common for payments above certain thresholds, configuration changes, or manual adjustments.

• Four-eye approval - two independent reviewers must sign off on certain actions. Often required for compliance decisions, AML escalations, or changes to risk parameters. Differs from maker-checker in that both parties are reviewing rather than one creating and one approving.

• Separation of duties - developers can’t access production data, ops can’t view PII, no single person can move money end-to-end without oversight.

• MFA - for employees accessing production, and for customers on high-value operations (PSD2 SCA requires it above €30). TOTP or WebAuthn tend to be more reliable than SMS.

11. Change Management & Safe Delivery

Most compliance frameworks require documented change control - PCI DSS, ISO 27001, SOC 2, and operational resilience regulations all have requirements here. It’s not bureaucracy - it’s forcing you to think before you break production. Gradual rollouts contain blast radius. Planned rollback capability means you’re not scrambling during incidents.

Some practices and processes you’re likely to encounter that help ensure auditability and reliability of changes:

• Infrastructure as Code - Terraform, Pulumi, CloudFormation. Every infrastructure change is code-reviewed, version-controlled, and reproducible.

• Immutable, signed artifacts - build once, deploy everywhere. Binary signing and cryptographic verification ensure what you tested is what you deploy. Helps prove to auditors that production matches approved builds.

• Blue-green deployments - run new version alongside old. Switch traffic only after validating new version works. Instant rollback: just switch traffic back.

• Canary releases - deploy to 1% of traffic first. Monitor error rates, latency, business metrics. If good, gradually increase to 5%, 10%, 50%, 100%. If bad, rollback immediately.

• Feature flags - decouple deployment from release. Deploy code with features disabled. Enable for internal users first, then gradually for customers. Kill switch if anything breaks.

• Automated testing gates - unit tests, integration tests, contract tests all must pass before deployment. Smoke tests after deployment verify system still works.

• Change approval workflows - high-risk changes (security updates, payment system changes) may require approval from senior engineer + SRE + compliance. Lower-risk changes can auto-deploy after CI passes.

• Runbooks - deployment procedures, rollback procedures, troubleshooting guides. Should be executable by on-call engineer at 3am without escalation.

• SBOM and supply chain security - Software Bill of Materials tracking all dependencies. SLSA framework for provenance.

12. KYC/AML & Transaction Monitoring

You can build the best payment system in the world, but if you’re used for money laundering, regulators will shut you down. AML violations carry unlimited fines and criminal liability for senior management - individuals can go to jail. Being associated with financial crime destroys trust permanently.

All regulated financial services must comply with AML regulations (UK: Money Laundering Regulations 2017; EU: 5th and 6th Anti-Money Laundering Directives etc.).

Key practices:

• KYC at onboarding - verify customer identity using document verification (passport, driving license) and liveness checks. Don’t build this yourself - use third-party providers like Onfido, Jumio, Persona. Collect: full name, date of birth, address, nationality. For businesses: company registration, beneficial ownership, directors.

• Risk-based approach - low-risk customers (small transactions, established patterns): lighter checks. High-risk (large transactions, high-risk countries, PEPs): enhanced due diligence.

• PEP screening - Politically Exposed Persons require enhanced checks. Use databases like Dow Jones, Refinitiv World-Check.

• Sanctions screening - check against OFAC, EU, UN sanctions lists. Do this at onboarding and continuously. Block transactions immediately if hit.

• Transaction monitoring - monitor for suspicious patterns: sudden large transactions, structuring (deliberately staying under reporting thresholds), round-trip transactions, high-risk countries. Set velocity rules: max £X per day, max Y transactions per hour. Adjust based on customer’s normal behavior.

• Suspicious Activity Reports (SARs) - when you detect suspicious activity, you must report to NCA (UK) or FIU (EU). Don’t tip off the customer - that’s illegal.

• Record keeping - keep KYC documents and transaction monitoring records for 5+ years (UK requirement). Regulators will ask for them during audits.

I always advise engineers to make sure any KYC/AML-related work is overseen by your MLRO (Money Laundering Reporting Officer) and compliance department. Get clear guidance from them on what actions to take and when - your job is to implement those rules, document them thoroughly, and make sure they’re testable. Don’t design AML logic in isolation.

13. Disaster Recovery & Business Continuity

Regulators don’t just want DR plans on paper. They want evidence you’ve tested them. Recently. And that they worked.

If you process £100M daily and you’re down for 4 hours, that’s £16M in blocked transactions. Some can’t wait - payroll, urgent payments, bill payments. And data loss in finance isn’t just inconvenient - it breaks your ledger, destroys trust, triggers regulatory investigations.

Key practices:

• Multi-region deployment - run active-passive or active-active across regions. For active-passive: automatic failover when primary region fails. For active-active: load balance across regions, more complex but better experience.

• Define RTO and RPO - RTO: how long can you be down? RPO: how much data can you afford to lose? For critical payment systems, these might be: RTO <30 minutes, RPO <1 minute.

• Point-in-time recovery for databases - continuous backups with ability to restore to any second. Test restores regularly - backups you haven’t tested are useless.

• Disaster recovery drills - actually fail over to backup region. Don’t just talk about it. Do it quarterly. In production. During business hours. Yes, really. This is how you find the problems.

• Runbooks for failover - step-by-step instructions for failing over. Should be executable by junior engineer at 2am. If it requires a senior engineer, you haven’t documented it properly.

• Backup verification - restore random backups weekly and verify data integrity. Corrupted backups are worse than no backups - you think you’re protected but you’re not.

• Immutable backups - use S3 Object Lock or similar to prevent accidental or malicious deletion of backups.

14. Vendor & Third-Party Risk

When your payment processor goes down, your users can’t pay. Regulators hold you responsible, not the vendor. Regulators don’t care that it was Stripe’s fault - you chose Stripe.

Vendor lock-in is real: if you build your entire system around one payment processor’s API and they raise prices 10x or shut down, you’re stuck. And if one vendor handles all your payment processing and they have an outage, your entire business stops.

Key practices:

• Vendor due diligence - before signing: review their SOC 2 reports, PCI compliance, security practices, financial stability. Cheap vendors might not exist in 2 years.

• Abstract payment providers - don’t call Stripe’s API directly everywhere. Build an abstraction layer. This makes switching providers possible.

• Dual-provider strategy for critical rails - primary provider + backup provider. If primary fails, automatically route to backup. Costs more but eliminates single point of failure.

• SLA enforcement and monitoring - track vendor uptime, error rates, latency. If they’re consistently missing SLAs, escalate or switch.

• Exit planning - document how you’d migrate off every vendor. What data needs exporting? What format? How long would migration take? Test exports regularly.

• Data portability - ensure you can export all your data in usable formats. Don’t be held hostage by proprietary formats.

• Data Processing Agreements (DPAs) - for GDPR compliance, you need DPAs with every vendor who processes EU personal data. They become your data processor, you remain controller, you’re liable for their mistakes.

Bottom Line

Building for fintech is different. The regulatory requirements aren’t bureaucracy - they’re forcing you to build systems that are auditable, secure, and reliable. That ultimately makes your systems better.

The compliance-velocity tension is real. Accept it. Build it into your process. Work with compliance, legal, and risk teams early - they’re not blockers, they’re keeping you out of jail and the company licensed.

The companies that succeed in fintech are the ones that embrace these constraints rather than fighting them. Regulation becomes your competitive moat - it’s hard to get right, so most competitors won’t. Build with discipline, move as fast as compliance allows, and remember that trust is the product you’re really selling.