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."
  }
}

Walkthroughs

• Individual vs business — which flow am I in? — The banking partner has two distinct customer types; start here to pick yours.
• Onboard an end-customer — Create a customer record + what its lifecycle looks like.
• Verify an end-customer — Upload documents + submit KYC for review.
• Issue a collection account — Provision per-customer international accounts (GBP / USD / EUR) or a CAD Interac address.

For the full endpoint reference — request/response schemas, fields, error codes, and code samples — see the Customers API reference. These walkthroughs explain when and why; the API reference is the what and how.

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.

Payout gating (individual flow)

For the individual flow, a GBP/USD/EUR payout sends from the sender’s own virtual account — so the sender must have an active VBA in that currency (issue one via POST /v1/customers/{id}/virtual_accounts). If they don’t, the payout is rejected with sender_account_not_provisioned. This is distinct from the business/treasury flow, where the gate checks the merchant’s international account (no_active_international_account). CAD goes via Interac for both. See Individual vs business for the full comparison.

Saving a recipient (POST /v1/beneficiaries) only requires the international-accounts feature flag — not an international account in that currency. The capability check happens at payout time, not at recipient-save time.

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.

What’s next