Loading…
Fintech
Cauridor moves money between African countries: remittances, mobile money transfers, and merchant settlement across corridors where the sending party might be in a diaspora market and the receiving party collects cash at an agent or a mobile wallet in a village.
The business proposition is simple to state and hard to run. The plumbing behind it is not a single payment network. It is a different set of integrations in every market: a mobile network operator here, a commercial bank there, an agent network somewhere else; each with its own protocol, uptime characteristics, and regulator with opinions about where data may be stored.
We joined when the platform was carrying real volume on infrastructure that had grown organically rather than been designed.
Three problems, all live at the same time, on a system that could not be taken offline.
Money in flight is not a retryable request. A failed API call in most businesses is an inconvenience. Here it is a customer whose rent transfer is stuck between two countries, a reconciliation exception, and potentially a regulatory report. Every reliability decision on this platform had to be made with that asymmetry in mind.
The critical dependencies sat outside the perimeter. Payout paths ran through mobile network operators reached over private connectivity rather than the public internet, without cloud-grade SLAs behind them. When an upstream gateway degraded at three in the morning, the platform had to fail in a way that was recoverable and auditable rather than silent.
Nobody could see anything. There was no metrics stack, centralised logging, or distributed tracing. Diagnosis meant connecting to a host and reading a file. Incident response depended on individual knowledge rather than shared tooling, which is not a reliability strategy at any scale.
We rebuilt the cloud footprint with workload separation, per-environment isolation, and centralised identity and logging. Corridor-specific and regulator-sensitive workloads were placed so that data residency commitments could be demonstrated on an architecture diagram rather than argued from a spreadsheet.
Everything was expressed in Terraform. Provisioning that had been manual and undocumented became reviewable, repeatable, and attributable to a pull request.
This mattered less for speed than for audit: when a regulator or a partner bank asked how an environment was configured, the answer became a commit rather than a recollection.
Each new market meant a new integration with a mobile money operator, over private connectivity into infrastructure we did not control, on change windows that belonged to someone else.
We standardised this into a repeatable pattern:
That distinction is worth more than it sounds. It is the difference between a forty-five-minute internal investigation and a phone call to the right party in the first five minutes.
We moved production workloads onto Amazon EKS incrementally, with the payment paths cut over last and rollback available at every step. Deployments moved to CI/CD pipelines with automated checks in front of production.
The visible outcome was availability that held through four years of continuous multi-market growth.
The less visible outcome mattered more day to day: a deployment stopped being an event. Releases went from something scheduled and feared to something routine, which changed how quickly the product team could respond to a partner API change or a new regulatory requirement.
We built the monitoring and logging layer that the whole engineering organisation ran on:
The purpose was self-service.
The goal was never to make one engineer better at diagnosis. It was to make waking that engineer unnecessary, and to let product engineers answer their own questions at three in the morning.
That is the outcome we would point to first.
We owned on-call and incident response and put structure around both:
Asynchronous processing was used to decouple the parts of the payment flow that could tolerate delay from the parts that could not, so that a slow downstream partner degraded throughput instead of taking the platform down.
Infrastructure spend was materially reduced through capacity planning, rightsizing, and removing the overprovisioning that is normal in an estate that grew without measurement.
Note the ordering: the observability work came first, and the cost reduction was possible because we could finally see actual utilisation. You cannot safely shrink what you cannot measure.
| Area | Capabilities |
|---|---|
| Cloud | AWS multi-account architecture, EKS, VPC design, private connectivity, IAM |
| Infrastructure as Code | Terraform |
| Containers & Orchestration | Docker, Kubernetes, Helm |
| CI/CD | Automated build, test, and deploy pipelines with production gating |
| Observability | Prometheus, Grafana, Loki, Elasticsearch |
| Engineering Practice | On-call rotation, incident response, postmortems, runbooks, capacity planning |
Most cloud platform work is done inside one regulatory regime, against dependencies that publish an SLA, for a business where a failed request can simply be retried.
This was none of those things.
The core skill was not any single technology on the list above. It was designing for partial failure in a system where the failing part belongs to somebody else, in a country whose regulator has its own view, while money is moving through it.
That is the experience we bring to fintech, telecom, and any platform whose reliability depends on integrations it does not control.
Observability before optimisation.
Instrument first. Every cost and performance decision after that is evidence-based rather than a guess.
Design the failure path per partner.
Treat every external integration as a first-class component with its own health signal, dashboard line, and runbook.
Make compliance an architectural property.
Data residency and audit are far cheaper as account structure and Terraform state than as a quarterly documentation exercise.
Cut over the money last.
Use incremental migration with rollback at every step, moving the highest-consequence path only once the pattern is proven.
Build for the team, not for the expert.
The measure of a platform is whether someone else can debug it at three in the morning without calling you.
We work in three shapes, and we will tell you honestly which one fits.
A defined engagement to design and deliver the foundation:
Senior infrastructure capacity inside your team, for organisations that need the seniority but not a full-time hire.
This is how the Cauridor engagement ran.
Ongoing ownership of monitoring, incident response, cost, and upgrades once the platform exists.
Most engagements start with a written review of a single environment—architecture, security posture, cost, and reliability risk—delivered inside five working days.
