Most fintech systems optimize for speed or compliance, but not both.
The result is weekend fire drills or missed markets.
Good engineering gives you both.
Building Fintech Systems That Stay Fast and Stay Compliant
Code BEAM Berlin 2025
Architecture choices that let you deploy on Friday and pass audits on Monday.
When payment systems break, you face regulatory fines and lost customer trust. This talk covers practical patterns for building fintech backends that handle millions of transactions without failing.
Ledger-first architecture. Typed money that survives JSON round-trips. Isolation boundaries that contain PSP failures. Audit trails that turn compliance into queries.
Patterns from Klarna, tested under pressure.
What You'll Learn
Ledger-First Architecture
Double-entry bookkeeping from day one. Every balance change is appended, never overwritten. Immutable data structures on the BEAM make this natural.
Typed Money
Never store money as floats or strings. Floats are for science calculations. Money is not science. Use integers with explicit currency and scale.
% Bad
Amount = 149.99.
% Good
Money = #{amount => 14999, currency => <<"SEK">>, scale => 2}.
BEAM Advantages
The BEAM runtime provides features that align perfectly with compliance requirements:
- Immutability → Auditability
- Process Isolation → Fault containment
- Arbitrary-precision integers → Processing integrity
- Supervision trees → Automated recovery
- Hot code loading → Zero-downtime updates
Isolation Boundaries
Keep ledger, orchestration, and PSP integrations separate. Each component runs in its own supervision tree. This maps directly to PCI and PSD2 segregation rules.
Audit Trail as Query
Design events so audits fall out of normal logging. Then an audit becomes a query, not a project.
{
"trace_id": "7b3bf470...",
"actor": "user:U123",
"timestamp": "2025-09-30T14:35:12Z",
"event": "payment.authorized",
"amount_before": 0,
"amount_after": 14999,
"psp": "AcmePay",
"region": "SE"
}
Merkle Proofs
Generate cryptographic proofs of account balances without revealing other accounts. This enables:
- Privacy: Prove one balance without revealing others
- Compact: Log N proof size (8 hashes for 256 accounts)
- Verifiable: Anyone can check the proof independently
- Historical: Prove state at any point in the immutable chain
Live Demonstrations
The presentation includes hands-on code demonstrations:
- Starting the Ledger: ETS-backed append-only chain with SHA256 hash verification
- Posting Transactions: Immutable history that enables audits as queries
- Merkle Root: Compact commitment to all balances for external verification
- Fault Containment: Heir pattern ensures data survives process crashes
- Balance Proofs: Generate and verify cryptographic proofs for specific accounts
All code is production-ready Erlang that you can adapt for your own systems.
Who Should Watch
This talk is designed for:
- Engineers building payment systems or financial infrastructure
- Teams facing compliance requirements (PSD2, GDPR, AML, PCI, SOC2)
- Developers who want to understand how BEAM enables both speed and reliability
- Anyone curious about cryptographic data structures in production systems
Technical Level
Intermediate to advanced
Assumes familiarity with Erlang/OTP concepts (processes, supervision trees, ETS). Code examples are in Erlang but the patterns apply to any BEAM language (Elixir, Gleam, etc.).
Duration
Approximately 30 minutes of content plus Q&A.
Key Takeaways
After watching this talk, you will understand:
- How to build ledger-first architectures that satisfy auditors
- Why typed money prevents precision errors in production
- How BEAM's concurrency model maps to compliance requirements
- How to use Merkle trees for cryptographic state verification
- Practical patterns for fault tolerance in financial systems
Fintech Scale Checklist
20 traps that stall growth.
Architecture traps. Compliance traps. Performance traps. Operations traps.
Each includes a BEAM-specific solution and timeline.
Building Scalable Fintech Systems
A field guide for practitioners. Coming Q2 2025.
Compliance without bureaucracy. YBYOYR culture. BEAM patterns for audit logging. Rolling releases in regulated environments.
For CTOs, developers, and compliance leads.
Why the BEAM
The BEAM was built for systems that move money and cannot fall over.
Processes are separated by default. Ledger entries are written once, never overwritten. Arbitrary-precision integers mean money values survive JSON round-trips.
Most compliance requirements map naturally to runtime properties the BEAM already has.
Related Resources
- The BEAM Book - Deep dive into the Erlang virtual machine
- BEAM Deep Dive Course - Comprehensive 6-module course on BEAM internals
- More Talks - All talks and presentations by Erik Stenman
