Senior Software Engineer, Deimos Cloud, Malik Adeyemi, in this interview he discusses practical issues in fintech architecture. Malik provides learnings from developing high-volume transaction systems at Deimos Cloud, where he created compliance engines to process 8M+ transactions daily across 20+ regulatory jurisdictions.

It appears that transaction limit tracking is deceptively simple, but with different regulations in various countries, how did you architect this at Deimos and not end up with a maintenance nightmare?
We solved it by getting all the compliance rules out of the business logic altogether. Rather than baking our regulatory framework into code we provided a configuration layer where regulations could be expressed by compliance officers in domain-specific expressions. Like they’d set something like “Nigeria daily transfer maximum: N500,000 rolling 24-hour window” through an administrative dashboard. These would be Parsed into executable workflows through our .NET Core backend. Since we needed to manage real-time performance, we used regional sharding, the EU transactions used one set of microservices and Nigerian transactions used another set of microservices by ISO country codes. Active thresholds were cached in Redis with sliding expiration windows that evolved to eliminate constant database queries while maintaining accuracy through Pub/Sub invalidation.

What were your methods to attain 99.99 percent uptime during such periods as Black Friday with the Buy-Now-Pay-Later operations?
The key was to design for asynchronous resilience. Instead of synchronous API calls, which break under load, we have transformed each payment into a state machine. In making a payment, we would create a unique correlation ID held in Cosmos DB. We would then work with payments webhook outcomes – completions, refunds, status change asynchronously. In the case of multi-step operations such as refund reversals we created Saga pattern using the concept of compensating transactions. When a step would fail, we would automatically undo what had been done. We also built in exponential backoff retries with dead-letter queues. It was very tasking but during load testing, we simulated 10,000 transactions per minute and confirmed the system could absorb third-party timeouts without cascading failures.

Data sovereignty becomes very important when handling transactions across borders. What kind of architecture is in the way of satisfying GDPR, PCI DSS, and regional requirements?
The idea of data partitioning turned out to be our strategic base. We sharded according to regulatory thresholds since the data involving transactions in Nigeria was on separate physical partitions as that involving transactions in the EU. This was not only performance, but this created natural compliance boundaries. We stored keys in HSM-backed Azure Key Vault, and with various cryptographic policy settings setting to regions. An implementation of audit trail was also interesting – we were able to use immutable cloud logging where every entry point carried cryptographic evidence of integrity, which made regulatory audit a much easier experience.

What advice would you give to those engineers who are building their first compliance system? Any hard-won lessons?
I have learnt a lot. Three things were invaluable, however: First, make compliance rules as configuration, but not as code. This saved us countless deployments when regulations changed. Second, implement payment operations as self healing state machines – these are your best friends. Third, think of observability at the DNA level early on. We have captured all transaction paths with OpenTelemetry and this played a critical role in helping us track timing bugs across our limit tracking engine. The moment you attempt to bolt on compliance or observability afterwards, you are defeated.