International accounts
International accounts give each of your customers their own foreign-currency account to receive and hold funds, so you can pay out on their behalf. GBP, USD, and EUR are held accounts; for CAD we set up an Interac routing address instead of a held account. This suits platforms that hold balances for their users, such as wallets, marketplaces, and diaspora apps. You register and verify each customer first, and it requires FX capabilities enabled on your account.
Technest is the licensed International Money Transfer Operator (IMTO), we’re the regulated entity. Each Swappr merchant using international accounts operates under their own licence (UK MSB, FinCEN MSB, Ghana RTO, etc.) and uses our infrastructure for the disbursement rail.
Being enabled for international accounts (per-customer accounts and the Customers API) is separate from having a sender-information requirement on your account. You can have either without the other. For the sender-information requirement, see Sender information.
Access
Requires FX capabilities enabled on your account. Sending in foreign currencies and issuing international accounts both use the same access. Contact Technest to enable it.
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 not enabled, every customer endpoint returns:
{
"error": {
"type": "permission_error",
"code": "fx_features_not_enabled",
"message": "FX capabilities are not enabled for your account. Contact Technest support to request access."
}
}Walkthroughs
- Which account does the payout leave from?: start here to pick whether funds leave your own account or a customer’s.
- Onboard an end-customer: create a customer record and see what its lifecycle looks like.
- Verify an end-customer: upload documents and submit KYC for review.
- Issue an international account: provision per-customer accounts in foreign currencies (see Currencies) 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 payouts
Money is still sent via POST /v1/payouts: international accounts do not have their own send-money endpoint. What is different when you use them:
- You create a customer (the account holder) once via the Customers API. Capture KYC and verify with our regulated KYC partner.
- You provision per-customer accounts for inflows in foreign currencies such as GBP, USD, and EUR (CAD uses Interac e-Transfer auto-deposit). See Currencies for the supported list.
- When sending payouts on behalf of a verified customer, pass
sender_customer_idon the payout body, so funds leave that customer’s account and Swappr attributes the payout to them. - If your account is a licensed money-services or remittance operator, include a
senderblock on each payout. See Sender information.
For the inflow side, our FX rail handles the upstream banking and webhooks land on your registered endpoint.
Which account does the payout leave from?
There are two ways to send in a foreign currency:
- From your own account: funds leave your merchant international account, with no per-customer setup (plain FX Payouts).
- From a customer’s account: each customer holds their own international account and funds leave from theirs (international accounts).
You pick per payout by whether you pass sender_customer_id. If you pass it, the customer must have an active account in that currency, or the payout is rejected with sender_account_not_provisioned. If you omit it, the payout leaves your merchant account, and a missing merchant account is rejected with no_active_international_account. CAD goes via Interac for both. See Which account does the payout leave from? for the full comparison.
Saving a recipient (POST /v1/beneficiaries) only requires FX capabilities enabled, 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:
| Country | Allowed id_type |
|---|---|
| NG | passport, drivers_license |
| CA | passport, drivers_license |
| GB | passport, drivers_license, resident_permit |
| US | passport, drivers_license |
| Business (any country) | certificate_of_incorporation |
Customers from outside the supported countries are rejected at create time with country_not_supported. Contact support if your remittance corridor needs a country we don’t yet cover.
Architectural notes
- One customer per end-user, per merchant: the
customer_referencefield 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_viewon a specific customer through admin tooling for compliance review. - Customer status lifecycle:
pending, then once KYC docs are uploaded and verified by our regulated partner,verifiedorrejected. Subscribe tocustomer_verified/customer_rejectedwebhooks. - An account requires a verified customer: provisioning a customer account refuses if the customer’s status isn’t
verified.