System Architecture · Corex Financial Systems

The infrastructure
behind a real
cross-border FX system.

Corex didn't start as code. It started as a WhatsApp operation moving AOA ↔ ZAR by hand — and every architectural decision below exists because I lived the operational problem it solves.

112 Java classes 15 production tables state-driven core full audit trail
01operational_context

Built from operational friction,
not from a tutorial.

Before a single line of Java, the business ran on messages, spreadsheets and trust. The architecture is a direct translation of those real constraints into a system.

// the manual reality
Coordination by hand
Matching a client who needs ZAR with a supplier holding ZAR — confirming rates, payments and timing manually over WhatsApp. Every step was a potential point of failure or dispute.
// the trust problem
Who pays first?
In P2P FX, the core tension is settlement order. The system encodes this with a state machine, payment verification and an immutable audit log — so trust comes from the structure, not from knowing someone personally.
// the scale problem
One operator, many transactions
Manual coordination doesn't scale past a handful of deals a day. Automated matching, timeouts and status transitions let the system carry the operational load that a person used to.
// the compliance problem
Everything must be traceable
Moving money across borders demands a record of every action. Audit logging isn't a feature bolted on — it's woven into each transition, so any transaction can be reconstructed end to end.
02operational_flow

How a single exchange
moves through the system.

From the moment a client requests an exchange to final settlement and audit. Scroll horizontally to follow the full path.

01 Client Request
02 Quote Engine
03 Supplier Matching
04 Payment Verification
05 Settlement
06 Audit Logging
07 Completed
03transaction_state_machine

Every transaction is
a finite set of states.

The lifecycle is explicit. A transaction can only move forward through defined transitions — and any deviation routes to a controlled terminal state.

PENDING_REQUEST awaiting intake
MATCHING_SUPPLIER finding liquidity
AWAITING_PAYMENT timeout-guarded
PAYMENT_CONFIRMED funds verified
SETTLING_FUNDS cross-border move
COMPLETED terminal · success
alternative terminal states
EXPIRED FAILED DISPUTED CANCELLED
04design_principles

The constraints that
shaped the system.

P_01
State before features
A money-moving system lives or dies on its state model. Before building any UI, the transaction lifecycle was defined as an explicit state machine — illegal transitions simply cannot happen.
P_02
Every action leaves a trace
Audit logging is not optional. Each transition writes an immutable record — who, what, when — so any transaction can be reconstructed and any dispute resolved against facts.
P_03
Time is a first-class actor
In FX, a stale quote is a liability. Automated timeout rules expire pending states and release matched liquidity, so the system never hangs waiting on a human that went quiet.
P_04
Trust encoded in structure
Instead of relying on personal relationships, trust scoring and payment verification make the settlement order safe between parties who have never met.
05implementation

What it runs on.

A deliberately boring, proven stack — chosen so the interesting complexity lives in the domain logic, not in the infrastructure.

Java 17 Spring Boot Spring Security PostgreSQL 15 Flyway JWT Auth REST API React State Machine Audit Logging

This is how I think
about your system too.

If you have an operational problem that needs to become real infrastructure — structure first, then execution — let's talk.

Let's Talk Back to Portfolio