Banking and financial services · East African operating environment

Transaction and reconciliation platform

A controlled transaction intake and reconciliation design for an institution that needed to replace spreadsheet-led exception handling without breaking existing settlement interfaces.

Core platform modernisationIllustrative scenario

Operations teams received transaction records through several channels. Each channel used a different reference format and cutoff schedule. Staff compared exports manually, recorded exceptions in shared files and relied on email to approve adjustments. The process worked while volumes were modest, but it left no single account of why a record had been accepted, held, retried or corrected.

The engagement did not begin with a promise to replace every upstream system. The safer boundary was a new reconciliation service that could accept current feeds, normalise identifiers, preserve source evidence and expose an operator workflow. Existing settlement and finance systems remained authoritative for their own records while the new platform owned matching state and exception decisions.

Operating constraints

Conditions the architecture had to respect

The delivery boundary was selected around external dependencies, data authority and the consequences of failure.

Upstream files and APIs could be late, duplicated or delivered out of sequence.

Operators needed to trace every adjustment to an actor, reason and source record.

The cutover could not assume that all counterparties would change their formats together.

Settlement windows required bounded retry and clear escalation instead of indefinite background processing.

Architecture

System boundary and operating flow

The architecture is described through ownership, state and recovery behaviour rather than a vendor diagram.

Adapters accepted batch files and synchronous API submissions into a common ingestion boundary. Each input received a source fingerprint and an idempotency key before processing. A durable queue separated receipt from parsing, validation and matching, so a slow downstream dependency could not block intake. Raw source artefacts were retained with access controls, while normalised records moved into a relational store with explicit reconciliation states.

Matching rules were versioned. A rule evaluation wrote the version, input references and result into the audit stream, which meant a later rule change did not rewrite the history of an earlier decision. Human exceptions entered a work queue with ownership, ageing and escalation. The design used a transactional outbox for events that informed reporting and downstream systems, preventing database commits and message publication from drifting apart.

Reconciliation completed at two levels. Record matching dealt with individual transactions. Control totals checked count and value across a complete source window. A batch could therefore appear healthy at the record level and still remain open if its control totals disagreed. Dashboards showed both states instead of compressing them into one green indicator.

Decisions and trade-offs

Choices made explicit

Each decision solved one operating risk while accepting a cost that the delivery team had to own.

Keep the matching core inside one deployable service.

ReasonRules shared a transaction boundary and were maintained by one operations domain.

Accepted trade-offIndependent scaling was limited, but rule changes and audits remained easier to reason about.

Preserve raw inputs alongside normalised records.

ReasonDisputes required evidence of exactly what each source supplied.

Accepted trade-offStorage and retention controls became more demanding, especially for sensitive source fields.

Run old and new reconciliation paths in parallel before cutover.

ReasonSide-by-side results exposed format assumptions and rule differences before operational ownership moved.

Accepted trade-offThe transition took longer and required explicit investigation of every unexplained variance.

Outcome and handover

Changed operating behaviour and ownership material

These are intended operating effects for the illustrative scenario, not measured results from a completed engagement.

Operating outcome

Operators received one queue for unmatched, duplicated, late and disputed records.

Every manual decision retained its actor, authority, reason and linked source evidence.

Replay could be scoped to a source window without duplicating already accepted transactions.

Finance teams could reconcile batch control totals separately from individual matching status.

Handover package

Versioned feed contracts and representative test fixtures

Rule catalogue with ownership and change procedure

Cutover reconciliation reports and rollback steps

Operator runbooks for late feeds, duplicate submissions and settlement exceptions