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.
International accounts are for individual customers. To collect for a business, contact us: businesses are onboarded with Technest directly.
Two ownership modes
GBP, USD and EUR are received through VIBANs: virtual IBANs and account numbers. A sender pays the VIBAN over their local or international rail (IBAN + BIC for EUR, sort code + account number for GBP, routing/account or SWIFT for USD), the funds settle to your merchant wallet, and Swappr fires a wallet_funded webhook. Who owns the VIBAN decides how the inflow is attributed:
| Customer international account | Your own treasury account | |
|---|---|---|
| Who owns it | One of your verified individual customers | You |
| Issued via | POST /v1/customers/{id}/virtual_accounts, see Issue an international account | Set up for you by Technest, see Wallet top-up account |
wallet_funded payload | Carries a customer block (customer.id, customer.customer_reference) | No customer block, a credit to your own books |
In both cases your merchant wallet is the account that’s credited. Branch on event.customer?.id: present means credit that customer; omitted means a credit to your own account. See Matching payments to customers.
Provisioning is asynchronous
A freshly issued VIBAN starts in provisioning while the real account number is allocated, and the account_number field stays empty until it lands. Subscribe to the virtual_account_activated webhook to know when it’s ready to receive.
Sandbox limitation: in the development environment, only NGN virtual accounts settle. GBP / USD / EUR VIBANs can be provisioned in sandbox and show as provisioning, but the account_number stays empty because no real bank-rail account is issued. Use sandbox for end-to-end testing of the create + provision flow; switch to live for actual inflow testing.
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.