No closed vendor list
A fixed set of provider names in the schema is a hardcoded vendor list wearing a constraint. Every provider interface here stays open, so the partner a group brings with it can be added rather than argued about.
Connections
Payout rails, screening, identity, messaging and evidence services sit behind canonical contracts inside the platform. Your integration is with Payzone; the provider behind a corridor is an operational decision, not a change to your code.
Every route is gated twice: the adapter has to exist, and the exact country and method has to be certified and enabled in the registry for your entity. A provider listed as Built · not enabled has an authenticated, reconciled contract implemented and tested, and is held disabled until certification and commercial activation complete. We list it that way rather than counting it as coverage.
| Provider | Capability | State |
|---|---|---|
| Thunes | Money Transfer v2 — quote create and read, transaction create, confirm and read, against the executed contract version. | Built · not enabled |
| Dahabshiil | Unified Remittance — token, account validation, send and transaction-detail polling, over allowlisted egress. | Built · not enabled |
| Pilot simulator | A rail that moves nothing, for proving the operation end to end. A simulating provider may only serve a simulated remittance and a live provider may only serve a real one — guarded in both directions, against a classification that cannot be edited after the fact. | Moves no money |
Settlement between principals is a separate thing from paying a recipient. How positions are netted and settled is on Clearing and settlement.
Payout partners are data, not a list compiled into the platform. Adding one is a record; it does not require a migration, a review and a release for what is a commercial fact about the world rather than a change to how the software works.
A fixed set of provider names in the schema is a hardcoded vendor list wearing a constraint. Every provider interface here stays open, so the partner a group brings with it can be added rather than argued about.
A partner that once carried payouts stays in the record permanently and is retired by status. It cannot be deleted while anything references it, because the transaction it executed still has to be explainable years later.
| Provider | Capability | State |
|---|---|---|
| Celmus | Sanctions and PEP screening, compliance holds, case management and MLRO decisions. Screening runs before authorisation and fails closed. | Implemented |
| Amazon Cognito | Invite-only workforce identity and fresh reauthentication. Operational authority remains derived from current database assignments. | Implemented |
| Entrust | Production evidence retrieval bound exactly to workflow, agent, country and write-once storage. | Implemented |
| Provider | Capability | State |
|---|---|---|
| Amazon SES | Transactional email with durable consent, budget, delivery and reconciliation controls. | Implemented |
| Twilio | SMS notification with the same consent, budget and delivery reconciliation boundary as email. | Implemented |
| Amazon Connect | Customer contact handled as a compliance record rather than as a separate support silo. | Implemented |
Each category has one canonical contract inside the platform. A provider implements it, is reconciled against it, and can be disabled without touching the transfer lifecycle or your integration.
Which provider executed a payout is recorded on the transaction. A route change is visible in the record, not hidden behind an abstraction.
An unknown provider outcome stays unknown until reconciled. Nothing is marked settled because a request returned 200.
Tell us the country, the method and the provider. We will tell you what implementing and certifying it involves, and what it does not.