PAYAZA GIVE BACK-OFFICE
Multi-currency settlement, designed as one queue.
Multi-currency, in most fintech products, is a feature. A tab. A toggle. A parallel product bolted onto the side of the primary one. The operator switches modes to move between them, and the seams show wherever two currencies have to be reconciled against each other. That’s not what multi-currency is.
Multi-currency is a property of the object, not a mode of the product. A settlement doesn’t happen in a currency; it has a currency, the way a transaction has a timestamp or a merchant has a country. Currency is a first-class attribute of every unit of work the back-office touches. Get the model right and seven currencies feel like one queue. Get it wrong and the operator carries the reconciliation in their head, which is where reconciliation goes to die.
Payaza Give Back-office handles seven currencies. NGN, GHS, TZS, USD, KSH, XOF, XAF. Each has its own rails, timing, partner banks, and FX margin. The design refuses to make the operator carry the difference.
The Model
Currency is modelled as a first-class attribute, not a filter. Every settlement carries the currency it accrued in. Every payout carries the currency it moves in and the currency it lands in, with the exchange rate as a stored property of the transaction. Every merchant carries the set of currencies they collect in and the currency they’ve chosen to settle in.
This means the back-office never has to ask “which currency queue am I looking at” as a routing question. The answer is always: all seven, aggregated where aggregation is meaningful, separated where separation is meaningful.
The dashboard aggregates across currencies at the top of the surface. Total payouts appear in every currency at once (NGN, GHS, TZS, USD, KSH, XOF, XAF) rather than requiring the operator to switch views. Total settlements aggregate across the merchant base without collapsing the currency dimension. The operator sees the shape of the platform’s day in one glance.
The queues separate where the operational reality requires it. A settlement in NGN and a settlement in USD move on different rails, in different windows, with different partner banks. The queue respects that. The filter is a lens, not a mode switch.
The Lifecycle
A settlement moves through four states: aggregating, awaiting settlement, ongoing, and completed. The states are identical across all seven currencies. What varies is the timing and the rail underneath.
The operator can pause a settlement, approve it, run an end-of-day process to force a stalled batch, or move it to the next state. Every action is logged with the admin’s name, the timestamp, the currency, and the merchant. The action log is the same log across all seven currencies, which means the audit trail reads as one platform’s history rather than as seven parallel ones.
Payouts add a currency-pair dimension on top. A merchant might collect in NGN and settle in USD. The payout carries the source currency, the destination currency, the exchange rate, and the two amounts (the amount to be withdrawn and the amount to receive). The operator sees the FX conversion inline. The rate isn’t hidden in a settings file; it’s a property of the transaction, stored with it, exportable with it.
A well-designed lifecycle is one an operator can learn once and apply seven times.
Approval and rejection both require a reason. A rejected payout carries the operator’s written explanation. That reason travels with the transaction into the audit trail and into the merchant’s notification. The operator can’t reject anonymously and can’t reject without articulating why.
The lifecycle holds regardless of which currency the settlement lives in. The operator learns the flow once and applies it seven times.
The Impact
The design decision that made this possible was refusing to treat currency as a mode. Most fintech back-offices, when they add multi-currency support, add it as a set of parallel products, a NGN dashboard, a USD dashboard, a GHS dashboard, each with its own queue, its own actions, and its own audit trail. The operator context-switches between them and the audit trail fragments across systems.
Payaza Give Back-office treats currency as a property of the object. Seven currencies live in one queue, one dashboard, one audit log. The operator learns the product once. Adding an eighth currency doesn’t require a new surface; it requires adding the currency to the object model. The design compounds instead of multiplying.
The operational effect is that the back-office team can scale the currency footprint without scaling the team. A new market can be supported without training a new operator on a new interface. A payout in a currency the team has never processed before still moves through the same flow, still carries the same metadata, still logs to the same audit trail.
The deeper move is that multi-currency in fintech isn’t a feature you add. It’s a shape you choose at the object-model level. Choose it early and the product absorbs new currencies as attributes. Choose it late and every new currency is a new product. Payaza Give Back-office was designed to absorb.