Value normalization
Some payment fields must end as one value from an Axiym-controlled vocabulary. Your request may supply either an accepted Axiym value or descriptive text. Axiym normalizes that input before validating the payment.
This happens for every payout, whether sender and receiver use Axiym's field
structure or a saved Party Data Map.
Normalization is AI-assisted, but its output is constrained to the documented allowed values for that field. Deterministic rules then decide whether the normalized result, required data, formats, and corridor requirements are valid. AI does not decide requiredness or approve a payout.
Mapping and normalization are different
Field-path mapping
A Party Data Map translates where sender and receiver fields are found in your objects. The reusable map contains field paths only.
Value normalization
Axiym interprets the value supplied in a controlled field for this payout and resolves it to one allowed Axiym value.
For example, a map can connect beneficiary.relation to
receiver.relationship. The value vendor providing IT services is then
normalized separately to the applicable Axiym relationship value.
Values that are normalized
Normalization applies only to payment-data fields that produce a controlled Axiym value, including:
- party identification type;
- UBO designation;
- receiver relationship;
- destination bank-account type;
- transaction purpose;
- source of funds; and
- supporting-document type.
Names, addresses, account numbers, references, document contents, country codes, and currency codes are not reclassified as business vocabulary values. They are validated according to their documented formats and corridor rules.
What happens during preparation
- Axiym applies a Party Data Map when
partyDataMapIdis supplied. - Exact accepted Axiym values pass through unchanged.
- Descriptive controlled values are normalized to allowed Axiym values.
- Deterministic schema, baseline, and destination rules validate the complete result.
- The prepared payout returns the final values for review.
If a supplied value cannot produce a valid allowed value, preparation fails with a field-level error. Normalization does not make missing data valid, decide requiredness, or approve the payment for execution.
Review before confirmation
The payout returned by POST /payouts has status PENDING_CONFIRMATION and
contains the final normalized paymentData. Review that exact instruction
before confirming it. Confirmation commits the prepared values; a material
correction requires a new payout.
Use Test payout data to see which representative values change without creating a quote or payout.