Remittances API

For merchants who pass sender info per transaction — typically remittance companies, IMTOs, MSBs, EMIs, payment institutions. The functional definition is what matters: if your business model is moving money on behalf of an end-user (not your own funds), you’re a remittance merchant in our terms.

Technest is the licensed International Money Transfer Operator (IMTO) — we’re the regulated entity. Each Swappr remittance merchant operates under their own licence (UK MSB, FinCEN MSB, Ghana RTO, etc.) and uses our infrastructure for the disbursement rail.

Gating

These endpoints require the Remittances feature flag on your account — a per-merchant gate set by Technest support after we’ve reviewed your licensing + AML programme.

To enable for your account, email support@the-technest.com with:

• Your registered legal entity name + jurisdiction
• License number + regulator
• Brief description of your money-movement use case
• Compliance officer contact details

If your account is gated off, every Remittances endpoint returns:

{
  "error": {
    "type": "permission_error",
    "code": "remittances_not_enabled",
    "message": "Remittances API not enabled for this merchant. Contact support."
  }
}

Resources

• Customers — Create + manage end-user records. KYC payload encrypted at rest.
• KYC submission — Upload documents + submit KYC for review.
• Customer VIBANs — Provision per-customer virtual IBANs (GBP / USD / EUR).

How it fits with the Universal API

Money is still sent via POST /v1/payouts — the Remittances API doesn’t have its own send-money endpoint. What’s different for Remittances merchants:

1. The sender block on every POST /v1/payouts becomes mandatory — required by CBN’s IMTO regulations + most international AML regimes. See the sender block reference for the exact fields (first/last name, ID type + number, ID expiry, DOB).
2. You create a customer (sender) once via the Remittances API. Capture KYC + verify with our regulated KYC partner.
3. You provision per-customer VIBANs for inflows in GBP/USD/EUR (CAD uses Interac e-Transfer auto-deposit).
4. When sending payouts on behalf of a verified customer, pass sender_customer_id on the payout body — Swappr attaches the sender identity from the customer’s stored KYC automatically. You don’t need to re-send the full sender block on every transaction.

For the inflow side (CAD / GBP / USD / EUR collections), our FX rail handles the upstream banking and webhooks land on your registered endpoint.

Country support

Today supported: NG, CA, GB, US.

ID type allowlist per country:

Architectural notes

• One customer per end-user, per merchant — the customer_reference field is your unique ID for the user (e.g. your internal user UUID). One customer maps to one upstream record server-side; we keep the mapping internal.
• PII at rest: KYC payloads (name, DOB, ID number, address, TIN) are AES-256-GCM encrypted in our DB using a key Technest controls. You can request a pii_view on a specific customer through admin tooling for compliance review.
• Customer status lifecycle: pending → (KYC docs uploaded + verified by our regulated partner) → verified OR rejected. Subscribe to customer_verified / customer_rejected webhooks.
• VIBANs require a verified customer: provisioning a VIBAN refuses if the customer’s status isn’t verified.