Schemas

Currency code — ISO 4217 (e.g. USD, EUR) or a supported digital currency (USDT, USDC).

ISO 3166-1 alpha-2 country code.

Decimal number serialized as a string to preserve precision.

Monetary amount and its currency.

Cursor information for a paginated response.

Code identifying the payment rail connected to the Axiym account, such as `ZENUS_BANK` or `TRON`. This is separate from the method used to deliver a payout.

Current availability of an Axiym account.

An account holding a currency balance. Receiving details for funding it are served by the deposit instructions.

Direction of movement on the account.

A posted ledger movement on an account. Entries are returned in posting order and carry the running balance, so consecutive entries reconcile against each other.

A payment route defined by the funding currency, destination country, and destination currency.

Current corridor availability. A payout can be created only when the corridor is `AVAILABLE`.

Permitted amount-to-receive range in the destination currency (`destinationCurrency`). Payout creation is rejected when the target amount is outside this range.

Additional field requirements and constraints for the selected corridor. Apply these alongside the baseline payout schemas.

Corridor-specific requirement for one payment-instruction field.

Structured postal address. `streetName` accepts the full primary address line; a separate `buildingNumber` is optional. See the field descriptions for supported address forms.

Contact details for a sender, recipient, or related individual.

Identification document or identifier type. The corridor determines which types are accepted.

Identification details returned in the prepared payment instruction.

Identification details supplied for a payment, using an exact Axiym identification type code.

Relationship of the recipient to the sender.

Sender or recipient details in Axiym's field structure, using exact controlled-value codes. Other labels require saved translations on the mapped endpoint.

Sender or recipient details returned with the payout, using Axiym field names and codes.

Origin of the sender's funds used for this payment. Use BUSINESS_INCOME for general business income not covered by a more specific category. INVESTMENT_INCOME covers investment returns such as interest and dividends; proceeds from selling investments use SALE_OF_OTHER_ASSETS. CAPITAL_CONTRIBUTION covers equity funding; shareholder and intercompany loans use LOAN_PROCEEDS.

Canonical role of an individual in relation to the party.

An individual related to the sender or recipient, and the role in which they are related.

Related individual details stored in the prepared payment instruction.

Sender details using Axiym field names and exact controlled-value codes. Corridor requirements may add evidence or other constraints.

Sender details stored in the prepared payment instruction, using Axiym field names and codes.

The party receiving the payment and its destination account, with canonical controlled values. `recipientId` is present when the recipient comes from the address book.

Reusable rules that transform your complete payment JSON into the Axiym payout input. Field paths are relative to the payment object sent to POST /payouts/mapped. The definition stores rules and reviewed labels, not payment records or file content. Definitions are immutable; store changed rules as a new map. Unsupported schema versions are rejected.

Name, optional description, and mapping definition to store.

ACTIVE maps can be used to create payouts. ARCHIVED maps are retained for audit and cannot be used for new payouts.

Payment Data Map stored for your integration. Its definition and content hash remain unchanged when it is archived.

Paginated list of stored Payment Data Maps.

Axiym classification of evidence supplied with a payout.

Reason for the payment. Each code corresponds to one ISO 20022 purpose code (ExternalPurpose1Code). SERVICES_PAYMENT covers every kind of service, including contractor, IT, legal and financial services. OWN_ACCOUNT_TRANSFER is between accounts of the same legal entity; INTERCOMPANY_TRANSFER is between separate companies in a group; TREASURY_MANAGEMENT is a group treasury operation. LOAN_REPAYMENT covers principal; INTEREST_PAYMENT covers interest. INVESTMENT is a financial investment; a property purchase uses REAL_ESTATE_PURCHASE. OTHER covers purposes outside the listed codes. Accepted purposes depend on the selected corridor.

A document supporting the payment, such as an invoice or contract. One item is one file; supply the file content as base64.

Creates a payout from a funding account, a fixed amount on one side, and complete payment instruction. Exactly one of `sourceAmount` or `destinationAmount` must be supplied. Sender and recipient data use Axiym's field structure.

A saved map identifier and one complete payment object in your agreed source structure. The map prepares the strict Axiym payout input, including payment details, parties, documents, and exactly one fixed amount. The prepared result must meet current corridor requirements.

- `PENDING_CONFIRMATION` — created with time-limited terms and awaiting confirmation. No funds are reserved. - `PENDING` — confirmed and awaiting or undergoing execution. - `HELD` — temporarily on hold; no action is required unless Axiym requests information. - `COMPLETED` — delivered successfully. - `CANCELED` or `REJECTED` — not completed; see `reasonCode` when present.

Compact account reference. Fetch the account via `GET /accounts/{accountId}` for the current balance and status; deposit instructions serve its payment details.

Common response document for an outgoing payment. Confirmation authorizes this exact document and reserves `sourceAmount`.

Metadata of a document accepted with the payment. File content is not returned.

Error response for requests that do not contain field-level validation failures.

Error response for field validation failures and business-rule rejections.

Nested validation errors keyed by field name or array index. Leaf values are arrays of `ValidationError` objects.

One field-level validation error.

Receiving bank address. Its country identifies the payout's destination country and determines the applicable bank-routing requirements. Supply additional address fields when required by the corridor.

Bank account to which the payout is delivered. Corridor requirements determine any additional routing fields.

Where the funds are delivered, as recorded on the operation at creation time. This is a snapshot: it carries the account or wallet details and, when the destination was taken from the address book, its `destinationId`. It does not carry the address book entry's status or creation date; read the address book entry for its current state. - A bank destination contains `accountNumber` and `bank`. - A wallet destination contains `walletAddress` and `network`. The two field sets never appear together.

Receiving bank details. The bank address country determines the destination corridor; additional routing fields depend on that corridor's requirements.

Receiving bank details returned with the payout, including the applicable clearing system.

Blockchain network of a wallet address.

Recipient details using Axiym field names and exact controlled-value codes. Corridor requirements may add identification, evidence, or routing requirements.

Exact partner labels mapped to PartyIdentificationType codes. Case and whitespace are significant. Many labels may map to the same code; only values used by your integration need entries. Existing Axiym codes pass unchanged and cannot be mapped to a different code.

Exact partner labels mapped to RelationshipRole codes. Case and whitespace are significant. Many labels may map to the same code; only values used by your integration need entries. Existing Axiym codes pass unchanged and cannot be mapped to a different code.

Exact partner labels mapped to SupportingDocumentType codes. Case and whitespace are significant. Many labels may map to the same code; only values used by your integration need entries. Existing Axiym codes pass unchanged and cannot be mapped to a different code.

Exact partner labels mapped to SourceOfFunds codes. Case and whitespace are significant. Many labels may map to the same code; only values used by your integration need entries. Existing Axiym codes pass unchanged and cannot be mapped to a different code.

Exact partner labels mapped to TransactionPurpose codes. Case and whitespace are significant. Many labels may map to the same code; only values used by your integration need entries. Existing Axiym codes pass unchanged and cannot be mapped to a different code.

Exact partner labels mapped to BusinessRelationship codes. Case and whitespace are significant. Many labels may map to the same code; only values used by your integration need entries. Existing Axiym codes pass unchanged and cannot be mapped to a different code.

Field path relative to the payment object in a mapped payout request. Use dots for nesting and [] for each array level, for example client.people[].fullName. The payment request wrapper is not part of the path. Keys contain letters, digits, or underscores; prototype-related keys are not allowed.

Field path within one file record. Dots represent nested objects. Array traversal is not supported within a file field.

Leaf in the Axiym payout input. amount.amount and amount.currency are intermediate fields resolved to sourceAmount or destinationAmount by amountResolution. Document fields are configured through documents.

Copies one source field to an Axiym field without type coercion. Include every field you intend to send, even if its name already matches Axiym. Unmapped input fields are ignored. Source and target paths must be unique across field rules. Array depth and order must match; fields belonging to the same target array must use the same source array.

Axiym document collection that receives the files. Requirements for that collection and its owner follow the payout input schema and selected corridor.

Fields within each source file containing its classification, filename, and complete base64 content. URLs and file identifiers do not replace content. A non-canonical document classification requires a value rule for this destination.

An exact ID equality linking a file to its destination record. All matches must hold. IDs must be non-empty strings or finite numbers; strings and numbers are not coerced. For identification evidence, include a match to the identification as well as the owner. Record paths within an array must follow the owner array established by the field rules.

Includes a file only when this field equals the saved string, including case and whitespace. All filters must match. Use stable tags to distinguish uses, such as party evidence and payment evidence.

Files are already nested with the payment, party, person, or identification they support. Ownership follows the source structure and established field mappings. No ID matches are needed. Separate owners or identifications cannot be inferred from file names or types.

Files are supplied in a separate collection. Match their IDs to the relevant records and optionally filter by usage tags. Each file in a configured source collection must resolve to exactly one destination across all connections; unmatched or ambiguous files cause payout creation to fail. Files retain source order within their destination collection.

Saved connection from one file collection to its Axiym destination. Ownership is determined by nesting or explicit ID matches. The same rules apply to every file on each payout.

Discriminator association

Reviewed exact translations for a SourceOfFunds field. The source and target must correspond to an existing field rule or document-type connection. A shared source, such as files[].kind, can have different translations for different document destinations.

Reviewed exact translations for a PartyIdentificationType field. The source and target must correspond to an existing field rule or document-type connection. A shared source, such as files[].kind, can have different translations for different document destinations.

Reviewed exact translations for a RelationshipRole field. The source and target must correspond to an existing field rule or document-type connection. A shared source, such as files[].kind, can have different translations for different document destinations.

Reviewed exact translations for a SupportingDocumentType field. The source and target must correspond to an existing field rule or document-type connection. A shared source, such as files[].kind, can have different translations for different document destinations.

Reviewed exact translations for a TransactionPurpose field. The source and target must correspond to an existing field rule or document-type connection. A shared source, such as files[].kind, can have different translations for different document destinations.

Reviewed exact translations for a BusinessRelationship field. The source and target must correspond to an existing field rule or document-type connection. A shared source, such as files[].kind, can have different translations for different document destinations.

A dictionary of exact labels for one controlled destination. Rules are unique by source and target. Translations apply after field and document mapping, independently to each array entry. Exact Axiym codes pass unchanged and cannot be redefined. Unknown labels, including differences in case or whitespace, are rejected. Missing optional data is omitted; there are no default values.

Compares the mapped amount currency with the funding account currency and recipient destination currency on each payout. A funding-currency match fixes sourceAmount; a recipient-only match fixes destinationAmount. If both match, sourceAmount is fixed. Invalid or unavailable required currency information, or a match to neither side, rejects the payout. The funding currency comes from Axiym account data, not the submitted payment.

Always treats the mapped amount as the selected side. Its currency must match that side: the Axiym funding account for sourceAmount, or the mapped recipient destination for destinationAmount. A mismatch rejects the payout.

How the intermediate amount.amount and amount.currency fields become exactly one of sourceAmount or destinationAmount in the prepared payout.

Discriminator method