Corridors and destinations

A cross-border payment uses funds held in an Axiym account to pay a beneficiary in another market's local currency. Axiym applies the quoted currency conversion, then delivers the buy amount through a supported local banking route.

That route is called a corridor.

A corridor is more specific than a destination country. It combines where the payment originates, the sell currency, the destination, the buy currency being delivered, and the payment method.

For example, USD from Singapore to PHP in the Philippines by bank payout is one corridor.

Change the destination, currency, or payment method and the requirements may change substantially.

Why corridors matter

Access varies

Corridor access is resolved from your partner agreement and can vary by destination, currency, and payment method.

Party data varies

One destination may require a local clearing code, another additional receiver identification, and another a different address or bank format.

Compliance varies

Local regulation, banking rules, payment-network requirements, transaction purpose, and supporting evidence can differ between corridors. Every payment is still reviewed against the applicable controls.

Limits and availability vary

Minimum and maximum amounts, operational availability, and supported delivery methods are resolved for the specific route.

For this reason, an integration should not treat every bank payout as the same request with a different country code. The corridor determines whether the route can be used and which information must be collected before the payment is submitted.

What defines a corridor

Field	Meaning
`originCountry`	Onboarded country of the partner. Axiym derives it.
`sellCurrency`	Currency sold from the Axiym account that funds the payment.
`destinationCountry`	Destination country for the beneficiary and bank payout.
`buyCurrency`	Local fiat currency bought and delivered to the beneficiary. Digital currencies are not payout currencies.
`payoutMethod`	How the beneficiary is paid. The currently supported value is `BANK`.
`availability`	Whether new quotes can currently be requested for the route.

The origin country is not supplied as a query parameter. Axiym derives it from the partner's onboarded location.

Baseline data and corridor requirements

Every payment has a stable baseline: sender, receiver, destination bank account, transaction context, and supporting evidence. This gives integrations one consistent top-level payment shape. The OpenAPI schemas describe that common structure.

The corridor then adds or tightens requirements such as:

receiver or business identification;
local bank, clearing, or routing codes;
country-specific value formats and validation patterns;
required address components;
permitted account or relationship types;
additional supporting evidence or compliance information; and
minimum and maximum payment amounts.

A field that is optional in the baseline model can therefore be required for a particular route. A value can also be valid in format but invalid for the selected destination. Corridor availability, data completeness, and payment approval are separate decisions.

How Axiym reduces the complexity

Discover

List only the corridors available to the partnership.

Understand

Use corridor details or the Country Playbook to see local requirements.

Map fields

Use Axiym's party structure or map the field paths in your existing sender and receiver objects.

Normalize values

Resolve controlled party, transaction, and document values to allowed Axiym values.

Validate

Axiym applies baseline and corridor rules before preparing the payment.

These tools keep destination-specific complexity from spreading through your integration. They do not remove the underlying requirements: the payment must still contain the information and evidence required for the selected corridor.

The Country Playbook presents destination requirements for an integrator.
The corridor details endpoint exposes the applicable requirements to an application.
The payout payload explains the common sender, receiver, transaction, and evidence structure.
Custom party data maps let you reuse existing sender and receiver structures.
The Payload Mapping Tool shows which party fields are covered, derived, or missing.
Test payout data applies value normalization and destination requirements without creating a quote or payout.

Discover available corridors

GET /corridors returns the routes available to the partnership. If no destination country or buy currency is supplied, it lists all available routes. Use query parameters to narrow the result.

GET /corridors?destinationCountry=PH&buyCurrency=PHP&payoutMethod=BANK

Do not hard-code corridor access. Retrieve the current list, inspect availability, and handle a route becoming unavailable.

Use corridors, accounts, quotes, and payouts returned in the same authenticated your integration.

Retrieve the requirements for one route

GET /corridors/details selects a corridor with query parameters and returns its current availability, amount limits, destination-specific fields, and compliance information.

GET /corridors/details?sellCurrency=USD&destinationCountry=PH&buyCurrency=PHP&payoutMethod=BANK

The response contains corridor-specific additions and overrides. It does not repeat fields required for every payment.

Discover the corridor and its requirements before requesting a quote. A quote fixes the financial terms for that route; it does not make incomplete party or transaction data valid, and it does not guarantee that the payment will pass compliance review.