Product

Business account

A multi-currency account for organisations: payouts, multiple authorised users, controls, reporting and the developer API.

Last updated 29 August 2026 — Draft for review. Product limits, availability and corridor detail to be confirmed by operations before publication.

What the account includes

  • Positions in the currencies your organisation trades in, each reported separately.
  • Single and batched payouts to suppliers, contractors and staff, with a review step before release.
  • Currency conversion at a quoted rate, with the exact recipient amount shown before you confirm.
  • Multiple authorised users, each individually verified with their own credentials.
  • Optional dual authorisation above a threshold you set with us.
  • Statements per currency and exportable records with a reference on every entry.
  • Access to the developer API for organisations that want to integrate directly.

Who can open one

The organisation must be validly registered in a market we serve, able to evidence its ownership and control, and operating in a sector within our appetite. Every beneficial owner, director and authorised user is verified individually. Ownership percentages must be declared in full and total exactly one hundred per cent.

Sectors outside our appetite are listed on the Anti-money laundering page. Where we cannot serve an organisation we say so as early in the process as we can.

Users, roles and authorisation

Each authorised user holds their own credentials and their own approved device. Shared logins are prohibited, both because they defeat the audit trail and because they make it impossible to attribute an instruction to a person.

You can require a second authoriser for payments above a threshold. Where dual authorisation applies, the person who prepares a payment cannot release it. Every preparation, approval and release is written to an append-only audit record with the user, the timestamp and the reference.

Removing a user's access takes effect immediately. It is the organisation's responsibility to keep the authorised user list current.

Payouts

A payout is prepared, reviewed and released. The review screen lists each recipient, the amount, the fee, the conversion rate where one applies and the total leaving each position. Nothing is released until a person with authority confirms it.

Each payout carries a reference and a single idempotency key, so a retry after a network failure cannot duplicate a payment. Failed payouts return to the originating position with a reason and a reference, and are visible in the outbound list alongside successful ones.

Reporting and reconciliation

Every movement appears on the statement for the currency it affected, with a date, a description, a direction, a reference and the position after it. Exports carry the same references so that your finance system can reconcile against our records without manual matching.

Amounts are reported in whole minor units with the currency code, so there is no ambiguity about scale or rounding when data is imported elsewhere.

Developer access

Organisations that want to integrate directly can use the developer API to create payments, read positions and receive event notifications. The API is described by a published specification, uses idempotency keys on every financial write, and returns deterministic errors with a request identifier.

Credentials are issued to the organisation, are scoped to the operations you need, and can be rotated or revoked at any time. See the Developers page for the specification and integration guidance.

Your obligations

Tell us within thirty days of a change to your registered details, your ownership, your controllers, your authorised users or the nature of your activity. Keep your credentials confidential and report any suspected compromise immediately.

Use the account only for the activity you described to us. Where activity diverges materially, we may ask for an explanation and, pending that explanation, restrict outbound payments.