Platform

The Platform section is consulted rather than worked. Two of its pages matter more than their position in the sidebar suggests.

Audit

Platform → Audit is every privileged action, against the staff member who took it.

It is written for every privileged act in the console — approvals, KYC decisions, limit and routing and pricing changes, data exports, erasures. That record is what makes it safe for the console to have the powers it has.

Read it when you need to establish what happened and when, which is usually during an incident or a dispute about a decision. It is also the reason individual staff accounts matter: a shared login produces an audit trail that names nothing, which is exactly as useful as no audit trail.

Data requests

Platform → Data requests handles data subject requests — somebody asking what we hold about them, or asking for it to be erased.

These have statutory deadlines. Missing one is a compliance failure, not a backlog, so this queue is not optional and not deferrable in the way others are.

Two things worth knowing:

Erasure is not deletion of everything. Transaction records are retained because we are required to retain them. The erasure path knows the difference; a hand-cleaned record does not. Run the request through the platform rather than editing anything by hand.

Every erasure in the platform goes through one path. That is deliberate, so the data-request route and the KYC purge cannot diverge and leave one of them quietly not erasing something. If you find a way to erase data that does not go through here, that is a bug and a compliance finding.

Export requests walk the data and produce a package. Check what is in it before it goes out: a package containing another person’s data is a new breach created while answering a request about the first one.

Workers

Platform → Workers shows the background jobs and when each last ran.

This is the page that tells you whether the platform is actually doing its work, and it is the most under-read page in the console.

The jobs behind it are the ones that settle money, publish events, poll partners for transaction outcomes and drain queues. A job that has stopped does not raise an error — it simply stops, and everything it was responsible for quietly stops with it. Transactions sit unresolved. Events are never published. Settlement does not run.

Silence is the failure mode

This codebase has shipped a complete, well-documented mechanism that nothing drove on four separate occasions — a webhook queue nobody filled, settlement batches nobody created, a notification queue nobody drained, and an entire risk module with no callers. Each one logged healthily while doing nothing.

A job whose last run is old is the visible form of exactly that failure. Check this page daily. “No errors” is not evidence that anything ran.

Staff

Platform → Staff is who has access to this console and what each of them may do.

267 of 287 console operations require a named permission, so a role here is the difference between a KYC reviewer and someone who can change routing.

• Grant by job, not by seniority.
• Review access when people change roles, not only when they leave.
• Remove access the day somebody leaves.
• Keep more than one person able to administer staff, so a departure is not an emergency.

Dual control means some actions need a second person. Make sure that second person exists on every shift — a control that cannot be satisfied at 2am gets worked around, and the workaround becomes the process.

Reference data

Platform → Reference data is the lists the platform resolves against: banks, mobile money networks, currencies, countries, FX rates.

Merchants read these through the gateway’s /v1/reference/* endpoints to resolve a network or bank to an id, so an entry added here appears in their integrations, and one removed stops resolving. Changes are small and their blast radius is not — removing a network every merchant’s checkout resolves by name will break those checkouts.