Say hi from Ezechukwu, Senior Software/Integrations Engineer

A platform that keeps businesses continuously compliant with Nigerian e-invoicing regulation, pulling invoices straight out of whatever ERP a client already runs and putting them in front of the tax authority in the shape it demands.

Problem

Compliance meant re-keying invoices by hand into a government schema, per invoice, per business, and every client ran a different ERP, several of them on-premise and untouchable.

Approach

A RAG-powered transformation service maps invoices from Sage and QuickBooks into FIRS-compliant schemas using LLM-based field mapping and anomaly detection, behind asynchronous event-driven microservices that talk to FIRS/NRS for authentication, validation, signing, confirmation, download, update, exchange and reporting. Legacy Sage X3 connects through a self-hosted Activepieces layer, so nothing on-premise had to change.

Cross-border settlement in minutes instead of days, without the fintech on top having to become a custodian. cixtech holds the keys, tracks whose money is whose and proves it is all still there, rented through one API. First tenant is a Nigerian payment gateway, and the design is deliberately jurisdiction-pluggable. I built the custody engine, not the payment product above it: ADR 0017 removed checkout, FX and fiat off-ramp from scope on purpose. Testnet only; mainnet is gated on a DASP licence and an external cryptographic audit, both documented as unmet.

Problem

Sending money across a border still moves through correspondent banking: days to settle, fees stacked at every hop, and for much of Africa, LATAM and South East Asia, routes that simply do not exist. Stablecoins fix the rail but move the problem rather than removing it. A business that wants to accept them has to become a custodian overnight: hold private keys for other people's money, know exactly whose money is whose, prove it is all still there, and satisfy a regulator. That is a licence, a security function and a double-entry accounting system, not a payments integration.

Approach

Three failure modes drove the design. First, small remittances are eaten by network fees: the obvious build gives each payment a fresh address and sweeps it to treasury, paying gas twice, often more than a $20 transfer is worth. Instead funds stay where they land in bounded per-merchant address pools and the merchant's payout is the sweep, so there is one on-chain movement per payment and fragmentation is capped by pool size rather than growing with every deposit. Second, merchants cannot tell whose money arrived, the most-cited operational complaint about crypto gateways, so attribution is structural: each invoice holds exclusive use of an address for its payment window, with a cool-off so a late payment is never credited to the next customer. No amount-matching, no guesswork. Third, custodians lose track of money, so the ledger proves that assets never fall below liabilities across every generated history including reorgs, replays and concurrent writes, reconciles continuously against on-chain state, and freezes withdrawals on drift rather than absorbing it quietly; client-asset segregation is demonstrable from the ledger, which is a licence condition, not a nicety. Underneath all three, tenant isolation is enforced by Postgres row-level security with a dedicated non-bypass role and insert-only grants on the ledger and audit tables, and every withdrawal clears limits, destination allow-listing with a cool-down, velocity caps, dual approval, a time-lock and a kill switch before anything is signed.

The access-control backbone for a multi-module ERP, plus the two workflow modules that most of the company touches every month.

Problem

Permissions were defined in a spreadsheet, pushed through Kafka into the platform. Nobody could review a permission change in a pull request, and every new module meant another XLS round-trip.

Approach

Moved the source of truth into code: a manifest-driven permission generation system that auto-registers permissions when a new module ships, replacing the XLS-and-Kafka pipeline entirely. Then built Leave Management and Expense Management on top of it: request APIs, leave types, balances, approvals, cash advances, retirement and workflow validation.