MX Pacs 008 001 10
MX Pacs 008 001 10
Standards MX
For the official documentation of the messages included in this publication, see the relevant Standards MX Message
Reference Guides available on swift.com > Support > Documentation
Standards MX
Table of Contents
1 MX pacs.008.001.10
FIToFICustomerCreditTransferV10
Usage
The FIToFICustomerCreditTransfer message is exchanged between agents and can contain one or
more customer credit transfer instructions.
- If the instructing agent and the instructed agent wish to use their direct account relationship in the
currency of the transfer then the message contains both the funds for the customer transfer(s) as well
as the payment details;
- If the instructing agent and the instructed agent have no direct account relationship in the currency
of the transfer, or do not wish to use their account relationship, then other (reimbursement) agents
will be involved to cover for the customer transfer(s). The FIToFICustomerCreditTransfer contains
only the payment details and the instructing agent must cover the customer transfer by sending a
FinancialInstitutionCreditTransfer to a reimbursement agent. This payment method is called the Cover
method;
- If more than two financial institutions are involved in the payment chain and if the
FIToFICustomerCreditTransfer is sent from one financial institution to the next financial institution in the
payment chain, then the payment method is called the Serial method.
A. GroupHeader
Set of characteristics shared by all individual transactions included in the message.
B. CreditTransferTransactionInformation
Set of elements providing information specific to the individual credit transfer(s).
C. SupplementaryData
Additional information that cannot be captured in the structured elements and/or any other specific
block.
3
Standards MX
1.2 Structure
Index Or MessageElement/BuildingBlock<XML Tag> Mult. Type Constr. Page
No.
5
Standards MX
7
Standards MX
9
Standards MX
11
Standards MX
1.3 Constraints
C1 ActiveCurrency ✓
(Rule)
The currency code must be a valid active currency code, not yet withdrawn on the day the
message containing the currency is exchanged. Valid active currency codes are registered
with the ISO 4217 Maintenance Agency, consist of three (3) contiguous letters, and are not yet
withdrawn on the day the message containing the Currency is exchanged. (Algorithm)
Error handling:
C2 ActiveOrHistoricCurrency ✓
(Rule)
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the
Currency is exchanged. (Algorithm)
Error handling:
C3 AnyBIC ✓
(Rule)
Only a valid Business identifier code is allowed. Business identifier codes for financial
or non-financial institutions are registered and published by the ISO 9362 Registration
Authority in the ISO directory of BICs, and consists of eight (8) or eleven (11) contiguous
characters. (Algorithm)
Error handling:
13
Standards MX
C4 BICFI ✓
(Rule)
Valid BICs for financial institutions are registered and published by the ISO 9362 Registration
Authority in the ISO directory of BICs, and consist of eight (8) or eleven (11) contiguous
characters. (Algorithm)
Error handling:
C5 ChargeBearerAndChargesInformationRule ✓
(Rule)
If ChargeBearer contains DEBT, then ChargesInformation may be present to communicate
charges that have been added for (the) InstructedAgent(s).
– Error Text: Invalid message content for charge bearer and charges information.
C6 ChargesAmountGuideline
(Guideline)
If ChargesInformation is present, then the currency of ChargesInformation/ChargesAmount is
recommended to be the same as the currency of InterbankSettlementAmount.
C7 ChargesInformationAndInstructedAmountRule ✓
(Rule)
If ChargesInformation is present, then InstructedAmount must be
present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for instructed amount when charges information is
present.
C8 ChargesInformationGuideline
(Guideline)
The repetitive ChargesInformation should contain all information on charges amount and which
party has taken the charges, separately for each agent along the payment chain.
C9 Country ✓
(Rule)
The code is checked against the list of country names obtained from the United Nations (ISO
3166, Alpha-2 code). (Algorithm)
Error handling:
C10 CurrencyAmount ✓
(Rule)
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
C11 CurrencyAmount ✓
(Rule)
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
C12 GroupHeaderInterbankSettlementDateRule ✓
(Rule)
If GroupHeader/InterbankSettlementDate is present, then
CreditTransferTransactionInformation/InterbankSettlementDate is not
allowed. (CrossElementComplexRule)
15
Standards MX
Error handling:
C13 IBAN ✓
(Rule)
A valid IBAN consists of all three of the following components: Country Code, check digits and
BBAN. (Algorithm)
Error handling:
C14 IdentificationAndProxyGuideline
(Guideline)
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
C15 IdentificationOrProxyPresenceRule ✓
(Rule)
Identification must be present or Proxy must be present. Both may be
present. (CrossElementSimpleRule)
Error handling:
C16 InstructedAgentRule ✓
(Rule)
If GroupHeader/InstructedAgent is present, then CreditTransferTransactionInformation/
InstructedAgent is not allowed. (CrossElementComplexRule)
Error handling:
C17 InstructedAmountAndExchangeRate1Rule ✓
(Rule)
If InstructedAmount is present and the currency is different from the
currency in InterbankSettlementAmount, then ExchangeRate must be
present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for exchange rate when instructed amount is present.
C18 InstructedAmountAndExchangeRate2Rule ✓
(Rule)
If InstructedAmount is present and the currency is the same as the currency in
InterbankSettlementAmount, then ExchangeRate is not allowed. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for exchange rate when instructed amount is not
present.
C19 InstructedAmountAndExchangeRate3Rule ✓
(Rule)
If InstructedAmount is not present, then ExchangeRate is not
allowed. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for exchange rate and instructed amount.
C20 InstructedReimbursementAgentAccountRule ✓
(Rule)
If InstructedReimbursementAgentAccount is present, then InstructedReimbursementAgent
must be present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for instructed reimbursement agent account.
C21 InstructingAgentRule ✓
(Rule)
17
Standards MX
C22 InstructingReimbursementAgentAccountRule ✓
(Rule)
If InstructingReimbursementAgentAccount is present, then InstructingReimbursementAgent
must be present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for instructing reimbursement agent account.
C23 InstructionForCreditorAgentRule ✓
(Rule)
If InstructionForCreditorAgent/Code contains CHQB (PayCreditorByCheque), then
CreditorAccount is not allowed. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for PayCreditorByCheque instruction for creditor agent.
C24 IntermediaryAgent1AccountRule ✓
(Rule)
If IntermediaryAgent1Account is present, then IntermediaryAgent1 must be
present. (CrossElementComplexRule)
Error handling:
C25 IntermediaryAgent2AccountRule ✓
(Rule)
If IntermediaryAgent2Account is present, then IntermediaryAgent2 must be
present. (CrossElementComplexRule)
Error handling:
C26 IntermediaryAgent2Rule ✓
(Rule)
If IntermediaryAgent2 is present, then IntermediaryAgent1 must be
present. (CrossElementComplexRule)
Error handling:
C27 IntermediaryAgent3AccountRule ✓
(Rule)
If IntermediaryAgent3Account is present, then IntermediaryAgent3 must be
present. (CrossElementComplexRule)
Error handling:
C28 IntermediaryAgent3Rule ✓
(Rule)
If IntermediaryAgent3 is present, then IntermediaryAgent2 must be
present. (CrossElementComplexRule)
Error handling:
C29 NumberOfTransactionsAndCreditTransfersRule
(Rule)
GroupHeader/NumberOfTransactions must equal the number of occurrences of
CreditTransferTransactionInformation. (CrossElementSimpleRule)
Error handling:
19
Standards MX
C30 PaymentTypeInformationRule ✓
(Rule)
If GroupHeader/PaymentTypeInformation is present, then
CreditTransferTransactionInformation/PaymentTypeInformation is not
allowed. (CrossElementComplexRule)
Error handling:
C31 PreviousInstructingAgent1AccountRule ✓
(Rule)
If PreviousInstructingAgent1Account is present, then PreviousInstructingAgent1 must be
present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for previous instructing agent 1 account.
C32 PreviousInstructingAgent1Guideline
(Guideline)
It is recommended that, when present, PreviousInstructingAgent1 is the closest to the
DebtorAgent in the payment chain.
C33 PreviousInstructingAgent2AccountRule ✓
(Rule)
If PreviousInstructingAgent2Account is present, then PreviousInstructingAgent2 must be
present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for previous instructing agent 2 account.
C34 PreviousInstructingAgent2Rule ✓
(Rule)
If PreviousInstructingAgent2 is present, then PreviousInstructingAgent1 must be
present. (CrossElementComplexRule)
Error handling:
C35 PreviousInstructingAgent3AccountRule ✓
(Rule)
If PreviousInstructingAgent3Account is present, then PreviousInstructingAgent3 must be
present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for previous instructing agent 3 account.
C36 PreviousInstructingAgent3Rule ✓
(Rule)
If PreviousInstructingAgent3 is present, then PreviousInstructingAgent2 must be
present. (CrossElementComplexRule)
Error handling:
C37 SettlementMethodAgentRule ✓
(Rule)
If SettlementMethod is equal to INDA or INGA, then ReimbursementAgent(s) and
ClearingSystem are not allowed. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for settlement method INGA or INDA.
C38 SettlementMethodClearingRule ✓
(Rule)
If SettlementMethod is equal to CLRG, then SettlementAccount and ReimbursementAgent(s)
are not allowed. (CrossElementComplexRule)
Error handling:
21
Standards MX
C39 SettlementMethodCoverAgentRule ✓
(Rule)
If SettlementMethod is equal to COVE, then InstructedReimbursementAgent or
InstructingReimbursementAgent must be present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for cover settlement method and reimbursement agents.
C40 SettlementMethodCoverRule ✓
(Rule)
If SettlementMethod is equal to COVE, then SettlementAccount and ClearingSystem are not
allowed. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for cover settlement method with settlement account
and clearing system.
C41 SupplementaryDataRule
(Rule)
The SupplementaryData building block at message level must not be used to provide additional
information about a transaction. The SupplementaryData element at transaction level should be
used for that purpose.
This constraint is defined at the MessageDefinition level.
C42 SupplementaryDataRule
(Rule)
This component may not be used without the explicit approval of a SEG and submission to the
RA of ISO 20022 compliant structure(s) to be used in the Envelope element.
C43 ThirdReimbursementAgentAccountRule ✓
(Rule)
If ThirdReimbursementAgentAccount is present, then ThirdReimbursementAgent must be
present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for third reimbursement agent account.
C44 ThirdReimbursementAgentRule ✓
(Rule)
If ThirdReimbursementAgent is present, then InstructingReimbursementAgent and
InstructedReimbursementAgent must both be present. (CrossElementComplexRule)
Error handling:
C45 TotalInterbankSettlementAmountAndDateRule ✓
(Rule)
If TotalInterbankSettlementAmount is present, then InterbankSettlementDate must be
present. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for group header interbank settlement date.
C46 TotalInterbankSettlementAmountAndSumRule
(Rule)
If GroupHeader/TotalInterbankSettlementAmount is present, then it must
equal the sum of all occurrences of CreditTransferTransactionInformation/
InterbankSettlementAmount. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for the total interbank settlement amount and sum of
individual interbank settlement amounts.
This constraint is defined at the MessageDefinition level.
C47 TotalInterbankSettlementAmountRule ✓
(Rule)
If GroupHeader/TotalInterbankSettlementAmount is present, then all occurrences
of CreditTransferTransactionInformation/InterbankSettlementAmount
must have the same currency as the currency of GroupHeader/
TotalInterbankSettlementAmount. (CrossElementComplexRule)
Error handling:
– Error Text: Invalid message content for the total interbank settlement amount and individual
interbank settlement amount currencies.
23
Standards MX
C48 TransactionIdentificationPresenceRule ✓
(Rule)
TransactionIdentification or UETR must be present. Both may be
present (CrossElementSimpleRule)
Error handling:
C49 TransactionInterbankSettlementDateRule ✓
(Rule)
If GroupHeader/InterbankSettlementDate is not present, then
CreditTransferTransactionInformation/InterbankSettlementDate must be
present. (CrossElementComplexRule)
Error handling:
C50 UltimateCreditorGuideline
(Guideline)
UltimateCreditor may only be present if different from Creditor.
C51 UltimateDebtorGuideline
(Guideline)
UltimateDebtor may only be present if different from Debtor.
InstructingReimbursementAgent [0..1] ± 35
<InstgRmbrsmntAgt>
25
Standards MX
Constraints
• TotalInterbankSettlementAmountAndDateRule
If TotalInterbankSettlementAmount is present, then InterbankSettlementDate must be present.
Error handling:
– Error Text: Invalid message content for group header interbank settlement date.
Usage: The instructing party has to make sure that MessageIdentification is unique per instructed party
for a pre-agreed period.
Datatype: Max35Text on page 238
Usage: Batch booking is used to request and not order a possible batch booking.
Datatype: One of the following values must be used (see BatchBookingIndicator on page 235):
• Meaning When True: Identifies that a batch entry for the sum of the amounts of all transactions in the
batch or message is requested.
• Meaning When False: Identifies that a single entry for each of the transactions in the batch or
message is requested.
Constraints
• ActiveCurrency
The currency code must be a valid active currency code, not yet withdrawn on the day the message
containing the currency is exchanged. Valid active currency codes are registered with the ISO 4217
Maintenance Agency, consist of three (3) contiguous letters, and are not yet withdrawn on the day
the message containing the Currency is exchanged.
27
Standards MX
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
29
Standards MX
Constraints
• InstructedReimbursementAgentAccountRule
If InstructedReimbursementAgentAccount is present, then InstructedReimbursementAgent must be
present.
Error handling:
– Error Text: Invalid message content for instructed reimbursement agent account.
• InstructingReimbursementAgentAccountRule
If InstructingReimbursementAgentAccount is present, then InstructingReimbursementAgent must be
present.
Error handling:
– Error Text: Invalid message content for instructing reimbursement agent account.
• SettlementMethodAgentRule
If SettlementMethod is equal to INDA or INGA, then ReimbursementAgent(s) and ClearingSystem
are not allowed.
Error handling:
– Error Text: Invalid message content for settlement method INGA or INDA.
• SettlementMethodClearingRule
If SettlementMethod is equal to CLRG, then SettlementAccount and ReimbursementAgent(s) are not
allowed.
Error handling:
• SettlementMethodCoverAgentRule
If SettlementMethod is equal to COVE, then InstructedReimbursementAgent or
InstructingReimbursementAgent must be present.
Error handling:
– Error Text: Invalid message content for cover settlement method and reimbursement agents.
• SettlementMethodCoverRule
If SettlementMethod is equal to COVE, then SettlementAccount and ClearingSystem are not allowed.
Error handling:
– Error Text: Invalid message content for cover settlement method with settlement account and
clearing system.
• ThirdReimbursementAgentAccountRule
If ThirdReimbursementAgentAccount is present, then ThirdReimbursementAgent must be present.
Error handling:
– Error Text: Invalid message content for third reimbursement agent account.
• ThirdReimbursementAgentRule
If ThirdReimbursementAgent is present, then InstructingReimbursementAgent and
InstructedReimbursementAgent must both be present.
Error handling:
31
Standards MX
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
33
Standards MX
Definition: Name of the account, as assigned by the account servicing institution, in agreement with the
account owner in order to provide an additional means of identification of the account.
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
Usage: If InstructingAgent and InstructedAgent have the same reimbursement agent, then only
InstructingReimbursementAgent must be used.
InstructingReimbursementAgent <InstgRmbrsmntAgt> contains the following elements (see
BranchAndFinancialInstitutionIdentification6 on page 155 for details)
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
35
Standards MX
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
Usage: If InstructingAgent and InstructedAgent have the same reimbursement agent, then only
InstructingReimbursementAgent must be used.
InstructedReimbursementAgent <InstdRmbrsmntAgt> contains the following elements (see
BranchAndFinancialInstitutionIdentification6 on page 155 for details)
37
Standards MX
Definition: Unambiguous identification of the account of the instructed reimbursement agent account at
its servicing agent in the payment chain.
Impacted by: ✓C15 IdentificationOrProxyPresenceRule ✓, C14 IdentificationAndProxyGuideline
InstructedReimbursementAgentAccount <InstdRmbrsmntAgtAcct> contains the following
CashAccount40 elements
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
Type <Tp> contains one of the following elements (see CashAccountType2Choice on page 142 for
details)
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
39
Standards MX
Proxy <Prxy> contains the following elements (see ProxyAccountIdentification1 on page 143 for
details)
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
41
Standards MX
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
43
Standards MX
45
Standards MX
47
Standards MX
49
Standards MX
51
Standards MX
Constraints
• ChargeBearerAndChargesInformationRule
If ChargeBearer contains DEBT, then ChargesInformation may be present to communicate charges
that have been added for (the) InstructedAgent(s).
– Error Text: Invalid message content for charge bearer and charges information.
• ChargesAmountGuideline
If ChargesInformation is present, then the currency of ChargesInformation/ChargesAmount is
recommended to be the same as the currency of InterbankSettlementAmount.
• ChargesInformationAndInstructedAmountRule
If ChargesInformation is present, then InstructedAmount must be present.
Error handling:
– Error Text: Invalid message content for instructed amount when charges information is present.
• ChargesInformationGuideline
The repetitive ChargesInformation should contain all information on charges amount and which party
has taken the charges, separately for each agent along the payment chain.
• InstructedAmountAndExchangeRate1Rule
If InstructedAmount is present and the currency is different from the currency in
InterbankSettlementAmount, then ExchangeRate must be present.
Error handling:
– Error Text: Invalid message content for exchange rate when instructed amount is present.
• InstructedAmountAndExchangeRate2Rule
If InstructedAmount is present and the currency is the same as the currency in
InterbankSettlementAmount, then ExchangeRate is not allowed.
Error handling:
– Error Text: Invalid message content for exchange rate when instructed amount is not present.
• InstructedAmountAndExchangeRate3Rule
If InstructedAmount is not present, then ExchangeRate is not allowed.
Error handling:
– Error Text: Invalid message content for exchange rate and instructed amount.
• InstructionForCreditorAgentRule
If InstructionForCreditorAgent/Code contains CHQB (PayCreditorByCheque), then CreditorAccount
is not allowed.
Error handling:
– Error Text: Invalid message content for PayCreditorByCheque instruction for creditor agent.
• IntermediaryAgent1AccountRule
If IntermediaryAgent1Account is present, then IntermediaryAgent1 must be present.
Error handling:
• IntermediaryAgent2AccountRule
If IntermediaryAgent2Account is present, then IntermediaryAgent2 must be present.
Error handling:
53
Standards MX
• IntermediaryAgent2Rule
If IntermediaryAgent2 is present, then IntermediaryAgent1 must be present.
Error handling:
• IntermediaryAgent3AccountRule
If IntermediaryAgent3Account is present, then IntermediaryAgent3 must be present.
Error handling:
• IntermediaryAgent3Rule
If IntermediaryAgent3 is present, then IntermediaryAgent2 must be present.
Error handling:
• PreviousInstructingAgent1AccountRule
If PreviousInstructingAgent1Account is present, then PreviousInstructingAgent1 must be present.
Error handling:
– Error Text: Invalid message content for previous instructing agent 1 account.
• PreviousInstructingAgent1Guideline
It is recommended that, when present, PreviousInstructingAgent1 is the closest to the DebtorAgent
in the payment chain.
• PreviousInstructingAgent2AccountRule
If PreviousInstructingAgent2Account is present, then PreviousInstructingAgent2 must be present.
Error handling:
– Error Text: Invalid message content for previous instructing agent 2 account.
• PreviousInstructingAgent2Rule
If PreviousInstructingAgent2 is present, then PreviousInstructingAgent1 must be present.
Error handling:
• PreviousInstructingAgent3AccountRule
If PreviousInstructingAgent3Account is present, then PreviousInstructingAgent3 must be present.
Error handling:
– Error Text: Invalid message content for previous instructing agent 3 account.
• PreviousInstructingAgent3Rule
If PreviousInstructingAgent3 is present, then PreviousInstructingAgent2 must be present.
Error handling:
• UltimateCreditorGuideline
UltimateCreditor may only be present if different from Creditor.
• UltimateDebtorGuideline
UltimateDebtor may only be present if different from Debtor.
55
Standards MX
Constraints
• TransactionIdentificationPresenceRule
TransactionIdentification or UETR must be present. Both may be present
Error handling:
Constraints
• ActiveCurrency
The currency code must be a valid active currency code, not yet withdrawn on the day the message
containing the currency is exchanged. Valid active currency codes are registered with the ISO 4217
Maintenance Agency, consist of three (3) contiguous letters, and are not yet withdrawn on the day
the message containing the Currency is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
57
Standards MX
Definition: Point in time when the payment order from the initiating party meets the processing
conditions of the account servicing agent. This means that the account servicing agent has received the
payment order and has applied checks such as authorisation, availability of funds.
Datatype: ISODateTime on page 232
Usage: This amount has to be transported unchanged through the transaction chain.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓, ✓C11 CurrencyAmount ✓
Datatype: ActiveOrHistoricCurrencyAndAmount on page 201
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
59
Standards MX
Definition: Factor used to convert an amount from one currency into another. This reflects the price at
which one currency was bought with another currency.
Datatype: BaseOneRate on page 235
Usage: If more than one previous instructing agent is present, then PreviousInstructingAgent1 identifies
the agent between the DebtorAgent and the PreviousInstructingAgent2.
PreviousInstructingAgent1 <PrvsInstgAgt1> contains the following elements (see
BranchAndFinancialInstitutionIdentification6 on page 155 for details)
61
Standards MX
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
Type <Tp> contains one of the following elements (see CashAccountType2Choice on page 142 for
details)
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
63
Standards MX
Proxy <Prxy> contains the following elements (see ProxyAccountIdentification1 on page 143 for
details)
Usage: If more than two previous instructing agent are present, then PreviousInstructingAgent2
identifies the agent between the PreviousInstructingAgent1 and the PreviousInstructingAgent3.
PreviousInstructingAgent2 <PrvsInstgAgt2> contains the following elements (see
BranchAndFinancialInstitutionIdentification6 on page 155 for details)
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
65
Standards MX
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
67
Standards MX
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Definition: Name of the account, as assigned by the account servicing institution, in agreement with the
account owner in order to provide an additional means of identification of the account.
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
69
Standards MX
Usage: If more than one intermediary agent is present, then IntermediaryAgent1 identifies the agent
between the DebtorAgent and the IntermediaryAgent2.
IntermediaryAgent1 <IntrmyAgt1> contains the following elements (see
BranchAndFinancialInstitutionIdentification6 on page 155 for details)
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
71
Standards MX
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
Usage: If more than two intermediary agents are present, then IntermediaryAgent2 identifies the agent
between the IntermediaryAgent1 and the IntermediaryAgent3.
IntermediaryAgent2 <IntrmyAgt2> contains the following elements (see
BranchAndFinancialInstitutionIdentification6 on page 155 for details)
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
73
Standards MX
Type <Tp> contains one of the following elements (see CashAccountType2Choice on page 142 for
details)
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
Proxy <Prxy> contains the following elements (see ProxyAccountIdentification1 on page 143 for
details)
Usage: If IntermediaryAgent3 is present, then it identifies the agent between the IntermediaryAgent 2
and the CreditorAgent.
IntermediaryAgent3 <IntrmyAgt3> contains the following elements (see
BranchAndFinancialInstitutionIdentification6 on page 155 for details)
75
Standards MX
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
77
Standards MX
Usage: This can be either the debtor or a party that initiates the credit transfer on behalf of the debtor.
InitiatingParty <InitgPty> contains the following elements (see PartyIdentification135 on page 172
for details)
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
79
Standards MX
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
Proxy <Prxy> contains the following elements (see ProxyAccountIdentification1 on page 143 for
details)
81
Standards MX
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
83
Standards MX
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
85
Standards MX
Definition: Name of the account, as assigned by the account servicing institution, in agreement with the
account owner in order to provide an additional means of identification of the account.
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
Constraints
• IdentificationAndProxyGuideline
If the account identification is not defined through a conventional identification such as an email
address or a mobile number, then the proxy element should be used for the identification of the
account.
• IdentificationOrProxyPresenceRule
Identification must be present or Proxy must be present. Both may be present.
Error handling:
87
Standards MX
Type <Tp> contains one of the following elements (see CashAccountType2Choice on page 142 for
details)
Usage: Currency should only be used in case one and the same account number covers several
currencies
and the initiating party needs to identify which currency needs to be used for settlement on the account.
Impacted by: ✓C2 ActiveOrHistoricCurrency ✓
Datatype: ActiveOrHistoricCurrencyCode on page 202
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Usage: The account name is different from the account owner name. The account name is used in
certain user communities to provide a means of identifying the account, in addition to the account
owner's identity and the account number.
Datatype: Max70Text on page 238
Proxy <Prxy> contains the following elements (see ProxyAccountIdentification1 on page 143 for
details)
89
Standards MX
The instruction can relate to a level of service, can be an instruction that has to be executed by the
agent, or can be information required by the next agent.
InstructionForNextAgent <InstrForNxtAgt> contains the following InstructionForNextAgent1
elements
Usage: Purpose is used by the end-customers, that is initiating party, (ultimate) debtor, (ultimate)
creditor to provide information concerning the nature of the payment. Purpose is a content element,
which is not used for processing by any of the agents involved in the payment chain.
Purpose <Purp> contains one of the following elements (see Purpose2Choice on page 165 for
details)
91
Standards MX
93
Standards MX
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
95
Standards MX
97
Standards MX
FromToDate <FrToDt> contains the following elements (see DatePeriod2 on page 145 for details)
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
99
Standards MX
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
101
Standards MX
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
103
Standards MX
Definition: Information supplied to enable the matching of an entry with the items that the transfer is
intended to settle, such as commercial invoices in an accounts' receivable system.
105
Standards MX
107
Standards MX
109
Standards MX
111
Standards MX
113
Standards MX
115
Standards MX
117
Standards MX
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
119
Standards MX
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
121
Standards MX
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
123
Standards MX
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
125
Standards MX
127
Standards MX
129
Standards MX
UltimateDebtor <UltmtDbtr> contains the following elements (see TaxParty2 on page 199 for
details)
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
131
Standards MX
133
Standards MX
Definition: Range of time between a start date and an end date for which the tax report is provided.
FromToDate <FrToDt> contains the following elements (see DatePeriod2 on page 145 for details)
135
Standards MX
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
Error handling:
137
Standards MX
FromToDate <FrToDt> contains the following elements (see DatePeriod2 on page 145 for details)
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
139
Standards MX
Constraints
• SupplementaryDataRule
This component may not be used without the explicit approval of a SEG and submission to the RA of
ISO 20022 compliant structure(s) to be used in the Envelope element.
Constraints
• SupplementaryDataRule
This component may not be used without the explicit approval of a SEG and submission to the RA of
ISO 20022 compliant structure(s) to be used in the Envelope element.
141
Standards MX
2.1 MessageComponents
2.1.1 Account
2.1.1.1 CashAccountType2Choice
Definition: Nature or use of the account.
2.1.1.2 GenericAccountIdentification1
Definition: Information related to a generic account identification.
2.1.1.3 ProxyAccountIdentification1
Definition: Information related to a proxy identification of the account.
143
Standards MX
Other <Othr> contains the following elements (see GenericAccountIdentification1 on page 142 for
details)
2.1.3 Charge
2.1.3.1 Charges7
Definition: Provides information on the charges related to the payment transaction.
145
Standards MX
147
Standards MX
Definition: Date of the final payment of a recurrent credit transfer as per the mandate.
Datatype: ISODate on page 232
Usage:
The reason will allow the user to distinguish between different mandates for the same creditor.
Reason <Rsn> contains one of the following MandateSetupReason1Choice elements
2.1.6 Document
2.1.6.1 CreditorReferenceInformation2
Definition: Reference information provided by the creditor to allow the identification of the underlying
documents.
149
Standards MX
Usage: If available, the initiating party should provide this reference in the structured remittance
information, to enable reconciliation by the creditor upon receipt of the amount of money.
If the business context requires the use of a creditor reference or a payment remit identification, and
only one identifier can be passed through the end-to-end chain, the creditor's reference or payment
remittance identification should be quoted in the end-to-end transaction identification.
Datatype: Max35Text on page 238
2.1.7.2 FinancialInstitutionIdentification18
Definition: Specifies the details to identify a financial institution.
151
Standards MX
PostalAddress <PstlAdr> contains the following elements (see PostalAddress24 on page 186 for
details)
153
Standards MX
2.1.7.3 BranchData3
Definition: Information that locates and identifies a specific branch of a financial institution.
PostalAddress <PstlAdr> contains the following elements (see PostalAddress24 on page 186 for
details)
2.1.7.4 BranchAndFinancialInstitutionIdentification6
Definition: Unique and unambiguous identification of a financial institution or a branch of a financial
institution.
155
Standards MX
Usage: This component should be used in case the identification information in the financial institution
component does not provide identification up to branch level.
BranchIdentification <BrnchId> contains the following elements (see BranchData3 on page 154 for
details)
2.1.7.5 GenericFinancialIdentification1
Definition: Information related to an identification of a financial institution.
2.1.8 Frequency
2.1.8.1 Frequency36Choice
Definition: Choice of format for a frequency, for example, the frequency of payment.
157
Standards MX
159
Standards MX
2.1.9.2 PaymentIdentification13
Definition: Provides further means of referencing a payment transaction.
Constraints
• TransactionIdentificationPresenceRule
TransactionIdentification or UETR must be present. Both may be present
Error handling:
Usage: The instruction identification is a point to point reference that can be used between the
instructing party and the instructed party to refer to the individual instruction. It can be included in
several messages related to the instruction.
Datatype: Max35Text on page 238
Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the
transaction. It can be included in several messages related to the transaction.
Usage: In case there are technical limitations to pass on multiple references, the end-to-end
identification must be passed on throughout the entire end-to-end chain.
Datatype: Max35Text on page 238
161
Standards MX
Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to
the transaction on the interbank level.
Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-
agreed period.
Datatype: Max35Text on page 238
2.1.10 Mandate
2.1.10.1 MandateClassification1Choice
Definition: Specifies the high level purpose of the instruction based on a set of pre-defined categories.
Usage: This is used by the initiating party to provide information concerning the processing of the
payment. It is likely to trigger special processing by any of the agents involved in the payment chain.
2.1.10.2 MandateTypeInformation2
Definition: Set of elements used to further detail the information related to the type of payment.
163
Standards MX
Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the
service or service level.
LocalInstrument <LclInstrm> contains one of the following LocalInstrument2Choice elements
2.1.11 Miscellaneous
2.1.11.1 SupplementaryData1
Definition: Additional information that can not be captured in the structured fields and/or any other
specific block.
Constraints
• SupplementaryDataRule
This component may not be used without the explicit approval of a SEG and submission to the RA of
ISO 20022 compliant structure(s) to be used in the Envelope element.
2.1.11.2 Purpose2Choice
Definition: Specifies the underlying reason for the payment transaction.
Usage: Purpose is used by the end-customers, that is initiating party, (ultimate) debtor, (ultimate)
creditor to provide information concerning the nature of the payment. Purpose is a content element,
which is not used for processing by any of the agents involved in the payment chain.
165
Standards MX
2.1.11.3 RemittanceAmount2
Definition: Nature of the amount and currency on a document referred to in the remittance section,
typically either the original amount due/payable or the amount actually remitted for the referenced
document.
167
Standards MX
169
Standards MX
171
Standards MX
173
Standards MX
PostalAddress <PstlAdr> contains the following elements (see PostalAddress24 on page 186 for
details)
2.1.13.2 Party38Choice
Definition: Nature or use of the account.
175
Standards MX
2.1.14 Payment
2.1.14.1 SettlementTimeRequest2
Definition: Provides information on the requested settlement time(s) of the payment instruction.
2.1.14.2 InstructionForCreditorAgent3
Definition: Further information related to the processing of the payment instruction that may need
to be acted upon by the creditor's agent. The instruction may relate to a level of service, or may be
an instruction that has to be executed by the creditor's agent, or may be information required by the
creditor's agent.
177
Standards MX
Definition: Coded information related to the processing of the payment instruction, provided by the
initiating party, and intended for the creditor's agent.
Datatype: ExternalCreditorAgentInstruction1Code on page 213
Definition: Specifies the clearing channel to be used to process the payment instruction.
Datatype: ClearingChannel2Code on page 205
Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the
service or service level.
179
Standards MX
Usage: This is used by the initiating party to provide information concerning the processing of the
payment. It is likely to trigger special processing by any of the agents involved in the payment chain.
CategoryPurpose <CtgyPurp> contains one of the following CategoryPurpose1Choice elements
181
Standards MX
2.1.16.2 Contact4
Definition: Specifies the details of the contact person.
183
Standards MX
185
Standards MX
187
Standards MX
189
Standards MX
191
Standards MX
2.1.19 Remittance
2.1.19.1 RemittanceLocation7
Definition: Provides information on the remittance advice.
2.1.19.2 Garnishment3
Definition: Provides remittance information about a payment for garnishment-related purposes.
193
Standards MX
195
Standards MX
2.1.19.3 RemittanceLocationData1
Definition: Provides additional details on the remittance advice.
197
Standards MX
2.1.21 Tax
2.1.21.1 TaxParty1
Definition: Details about the entity involved in the tax paid or to be paid.
2.1.21.2 TaxParty2
Definition: Details about the entity involved in the tax paid or to be paid.
199
Standards MX
Format
minInclusive 0
totalDigits 18
fractionDigits 5
Constraints
• ActiveCurrency
The currency code must be a valid active currency code, not yet withdrawn on the day the message
containing the currency is exchanged. Valid active currency codes are registered with the ISO 4217
Maintenance Agency, consist of three (3) contiguous letters, and are not yet withdrawn on the day
the message containing the Currency is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
2.2.1.2 ActiveOrHistoricCurrencyAndAmount
Definition: A number of monetary units specified in an active or a historic currency where the unit of
currency is explicit and compliant with ISO 4217.
Type: Amount
This data type contains the following XML attribute:
Format
minInclusive 0
totalDigits 18
fractionDigits 5
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.
201
Standards MX
2.2.2 Binary
2.2.2.1 Max10KBinary
Definition: Binary data of 10K maximum.
Type: Binary
Format
minLength 1
maxLength 10240
2.2.3 CodeSet
2.2.3.1 ActiveCurrencyCode
Definition: A code allocated to a currency by a Maintenance Agency under an international identification
scheme as described in the latest edition of the international standard ISO 4217 "Codes for the
representation of currencies and funds".
Type: CodeSet
Format
pattern [A-Z]{3,3}
Constraints
• ActiveCurrency
The currency code must be a valid active currency code, not yet withdrawn on the day the message
containing the currency is exchanged. Valid active currency codes are registered with the ISO 4217
Maintenance Agency, consist of three (3) contiguous letters, and are not yet withdrawn on the day
the message containing the Currency is exchanged.
Error handling:
Restricts
ParentCurrencyCode on page 225
2.2.3.2 ActiveOrHistoricCurrencyCode
Definition: A code allocated to a currency by a Maintenance Agency under an international identification
scheme, as described in the latest edition of the international standard ISO 4217 "Codes for the
representation of currencies and funds".
Type: CodeSet
Format
pattern [A-Z]{3,3}
Constraints
• ActiveOrHistoricCurrency
The Currency Code must be registered, or have already been registered. Valid active or historic
currency codes are registered with the ISO 4217 Maintenance Agency, consist of three (3)
contiguous letters, and may be or not be withdrawn on the day the message containing the Currency
is exchanged.
Error handling:
Restricts
ParentCurrencyCode on page 225
2.2.3.3 AddressType2Code
Definition: Specifies the type of address.
Type: CodeSet
Restricts
AddressTypeCode on page 203
2.2.3.4 AddressTypeCode
Definition: Specifies the type of address.
Type: CodeSet
203
Standards MX
Is restricted by
AddressType2Code on page 203
2.2.3.5 AmountDirectionCode
Definition: Specifies if an operation is an increase or a decrease or the result of a reversal operation.
Type: CodeSet
Is restricted by
CreditDebitCode on page 206
2.2.3.6 ChargeBearerType1Code
Definition: Specifies which party(ies) will pay charges due for processing of the instruction.
Type: CodeSet
Restricts
ChargeBearerTypeCode on page 205
2.2.3.7 ChargeBearerTypeCode
Definition: Specifies which party(ies) will pay charges due for processing of the instruction.
Type: CodeSet
Is restricted by
ChargeBearerType1Code on page 204
2.2.3.8 ClearingChannel2Code
Definition: Specifies the clearing channel for the routing of the transaction, as part of the payment type
identification.
Type: CodeSet
Restricts
ClearingChannelCode on page 205
2.2.3.9 ClearingChannelCode
Definition: Specifies the clearing channel for the routing of the transaction, as part of the payment type
identification.
205
Standards MX
Type: CodeSet
Is restricted by
ClearingChannel2Code on page 205
2.2.3.10 CountryCode
Definition: Code to identify a country, a dependency, or another area of particular geopolitical interest,
on the basis of country names obtained from the United Nations (ISO 3166, Alpha-2 code).
Type: CodeSet
Format
pattern [A-Z]{2,2}
Constraints
• Country
The code is checked against the list of country names obtained from the United Nations (ISO 3166,
Alpha-2 code).
Error handling:
2.2.3.11 CreditDebitCode
Definition: Specifies if an operation is an increase or a decrease.
Type: CodeSet
Restricts
AmountDirectionCode on page 204
2.2.3.12 DocumentType3Code
Definition: Specifies a type of financial or commercial document.
Type: CodeSet
Restricts
DocumentTypeCode on page 208
2.2.3.13 DocumentType6Code
Definition: Specifies a type of financial or commercial document.
Type: CodeSet
207
Standards MX
Restricts
DocumentTypeCode on page 208
2.2.3.14 DocumentTypeCode
Definition: Specifies a type of financial or commercial document.
Type: CodeSet
Is restricted by
DocumentType3Code on page 207, DocumentType6Code on page 207
2.2.3.15 ExternalAccountIdentification1Code
Definition: Specifies the external account identification scheme name code in the format of character
string with a maximum length of 4 characters.
209
Standards MX
Format
minLength 1
maxLength 4
Restricts
ExternalAccountIdentificationCode on page 210
2.2.3.16 ExternalAccountIdentificationCode
Definition: Specifies the external account identification scheme name code in the format of character
string with a maximum length of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalAccountIdentification1Code on page 209
2.2.3.17 ExternalCashAccountType1Code
Definition: Specifies the nature, or use, of the cash account in the format of character string with a
maximum length of 4 characters.
Format
minLength 1
maxLength 4
Restricts
ExternalCashAccountTypeCode on page 210
2.2.3.18 ExternalCashAccountTypeCode
Definition: Specifies the nature, or use, of the cash account in the format of character string with a
maximum length of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalCashAccountType1Code on page 210
2.2.3.19 ExternalCashClearingSystem1Code
Definition: Specifies the cash clearing system, as published in an external cash clearing system code
list.
Format
minLength 1
maxLength 3
Restricts
ExternalCashClearingSystemCode on page 211
2.2.3.20 ExternalCashClearingSystemCode
Definition: Specifies the cash clearing system, as published in an external cash clearing system code
list.
Format
minLength 1
maxLength 4
Is restricted by
ExternalCashClearingSystem1Code on page 211
2.2.3.21 ExternalCategoryPurpose1Code
Definition: Specifies the category purpose, as published in an external category purpose code list.
211
Standards MX
Format
minLength 1
maxLength 4
Restricts
ExternalCategoryPurposeCode on page 212
2.2.3.22 ExternalCategoryPurposeCode
Definition: Specifies the category purpose, as published in an external category purpose code list.
Format
minLength 1
maxLength 4
Is restricted by
ExternalCategoryPurpose1Code on page 211
2.2.3.23 ExternalClearingSystemIdentification1Code
Definition: Specifies the clearing system identification code, as published in an external clearing system
identification code list.
Format
minLength 1
maxLength 5
Restricts
ExternalClearingSystemIdentificationCode on page 212
2.2.3.24 ExternalClearingSystemIdentificationCode
Definition: Specifies the clearing system identification code, as published in an external clearing system
identification code list.
Format
minLength 1
maxLength 5
Is restricted by
ExternalClearingSystemIdentification1Code on page 212
2.2.3.25 ExternalCreditorAgentInstruction1Code
Definition: Specifies further instructions concerning the processing of a payment instruction, as provided
to the creditor agent.
Type: CodeSet
Format
minLength 1
maxLength 4
Restricts
ExternalCreditorAgentInstructionCode on page 213
2.2.3.26 ExternalCreditorAgentInstructionCode
Definition: Specifies further instructions concerning the processing of a payment instruction, as provided
to the creditor agent.
Type: CodeSet
Format
minLength 1
maxLength 4
Is restricted by
ExternalCreditorAgentInstruction1Code on page 213
2.2.3.27 ExternalDiscountAmountType1Code
Definition: Specifies the nature, or use, of the amount in the format of character string with a maximum
length of 4 characters.
Format
minLength 1
maxLength 4
213
Standards MX
Restricts
ExternalDiscountAmountTypeCode on page 214
2.2.3.28 ExternalDiscountAmountTypeCode
Definition: Specifies the nature, or use, of the amount in the format of character string with a maximum
length of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalDiscountAmountType1Code on page 213
2.2.3.29 ExternalDocumentLineType1Code
Definition: Specifies the document line type as published in an external document type code list.
Type: CodeSet
Format
minLength 1
maxLength 4
Restricts
ExternalDocumentLineTypeCode on page 214
2.2.3.30 ExternalDocumentLineTypeCode
Definition: Specifies the document line type as published in an external document type code list.
Type: CodeSet
Format
minLength 1
maxLength 4
Is restricted by
ExternalDocumentLineType1Code on page 214
2.2.3.31 ExternalFinancialInstitutionIdentification1Code
Definition: Specifies the external financial institution identification scheme name code in the format of
character string with a maximum length of 4 characters.
Format
minLength 1
maxLength 4
Restricts
ExternalFinancialInstitutionIdentificationCode on page 215
2.2.3.32 ExternalFinancialInstitutionIdentificationCode
Definition: Specifies the external financial institution identification scheme name code in the format of
character string with a maximum length of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalFinancialInstitutionIdentification1Code on page 215
2.2.3.33 ExternalGarnishmentType1Code
Definition: Specifies the garnishment type as published in an external document type code list.
Type: CodeSet
Format
minLength 1
maxLength 4
Restricts
ExternalGarnishmentTypeCode on page 216
215
Standards MX
2.2.3.34 ExternalGarnishmentTypeCode
Definition: Specifies the garnishment type as published in an external document type code list.
Type: CodeSet
Format
minLength 1
maxLength 4
Is restricted by
ExternalGarnishmentType1Code on page 215
2.2.3.35 ExternalLocalInstrument1Code
Definition: Specifies the external local instrument code in the format of character string with a maximum
length of 35 characters.
Format
minLength 1
maxLength 35
Restricts
ExternalLocalInstrumentCode on page 216
2.2.3.36 ExternalLocalInstrumentCode
Definition: Specifies the external local instrument code in the format of character string with a maximum
length of 35 characters.
Format
minLength 1
maxLength 35
Is restricted by
ExternalLocalInstrument1Code on page 216
2.2.3.37 ExternalMandateSetupReason1Code
Definition: Specifies the external mandate setup reason code in the format of character string with a
maximum length of 4 characters.
Format
minLength 1
maxLength 4
Restricts
ExternalMandateSetupReasonCode on page 217
2.2.3.38 ExternalMandateSetupReasonCode
Definition: Specifies the external mandate setup reason code in the format of character string with a
maximum length of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalMandateSetupReason1Code on page 217
2.2.3.39 ExternalOrganisationIdentification1Code
Definition: Specifies the external organisation identification scheme name code in the format of
character string with a maximum length of 4 characters.
Format
minLength 1
maxLength 4
Restricts
ExternalOrganisationIdentificationCode on page 218
217
Standards MX
2.2.3.40 ExternalOrganisationIdentificationCode
Definition: Specifies the external organisation identification scheme name code in the format of
character string with a maximum length of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalOrganisationIdentification1Code on page 217
2.2.3.41 ExternalPersonIdentification1Code
Definition: Specifies the external person identification scheme name code in the format of character
string with a maximum length of 4 characters.
Format
minLength 1
maxLength 4
Restricts
ExternalPersonIdentificationCode on page 218
2.2.3.42 ExternalPersonIdentificationCode
Definition: Specifies the external person identification scheme name code in the format of character
string with a maximum length of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalPersonIdentification1Code on page 218
2.2.3.43 ExternalProxyAccountType1Code
Definition: Specifies the external proxy account type code, as published in the proxy account type
external code set.
Format
minLength 1
maxLength 4
Restricts
ExternalProxyAccountTypeCode on page 219
2.2.3.44 ExternalProxyAccountTypeCode
Definition: Specifies the external proxy account type code, as published in the proxy account type
external code set.
Format
minLength 1
maxLength 4
Is restricted by
ExternalProxyAccountType1Code on page 219
2.2.3.45 ExternalPurpose1Code
Definition: Specifies the external purpose code in the format of character string with a maximum length
of 4 characters.
Format
minLength 1
maxLength 4
219
Standards MX
Restricts
ExternalPurposeCode on page 220
2.2.3.46 ExternalPurposeCode
Definition: Specifies the external purpose code in the format of character string with a maximum length
of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalPurpose1Code on page 219
2.2.3.47 ExternalServiceLevel1Code
Definition: Specifies the external service level code in the format of character string with a maximum
length of 4 characters.
Format
minLength 1
maxLength 4
Restricts
ExternalServiceLevelCode on page 220
2.2.3.48 ExternalServiceLevelCode
Definition: Specifies the nature, or use, of the amount in the format of character string with a maximum
length of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalServiceLevel1Code on page 220
2.2.3.49 ExternalTaxAmountType1Code
Definition: Specifies the nature, or use, of the amount in the format of character string with a maximum
length of 4 characters.
Format
minLength 1
maxLength 4
Restricts
ExternalTaxAmountTypeCode on page 221
2.2.3.50 ExternalTaxAmountTypeCode
Definition: Specifies the nature, or use, of the amount in the format of character string with a maximum
length of 4 characters.
Format
minLength 1
maxLength 4
Is restricted by
ExternalTaxAmountType1Code on page 221
2.2.3.51 Frequency6Code
Definition: Specifies the regularity of an event.
Type: CodeSet
221
Standards MX
Restricts
FrequencyCode on page 222
2.2.3.52 FrequencyCode
Definition: Specifies the regularity of an event.
Type: CodeSet
Is restricted by
Frequency6Code on page 221
2.2.3.53 Instruction4Code
Definition: Specifies further instructions concerning the processing of a payment instruction, provided by
the sending clearing agent to the next agent(s).
Type: CodeSet
Restricts
InstructionCode on page 223
2.2.3.54 InstructionCode
Definition: Specifies further instructions concerning the processing of a payment instruction.
Type: CodeSet
223
Standards MX
Is restricted by
Instruction4Code on page 223
2.2.3.55 MandateClassification1Code
Definition: Specifies the type of direct debit amount, such as fixed or variable.
Type: CodeSet
Restricts
MandateClassificationCode on page 224
2.2.3.56 MandateClassificationCode
Definition: Specifies the type of direct debit amount, such as fixed or variable.
Type: CodeSet
Is restricted by
MandateClassification1Code on page 224
2.2.3.57 NamePrefix2Code
Definition: Specifies the terms used to formally address a person.
Type: CodeSet
Restricts
NamePrefixCode on page 225
2.2.3.58 NamePrefixCode
Definition: Specifies the terms used to formally address a person.
Type: CodeSet
Is restricted by
NamePrefix2Code on page 224
2.2.3.59 ParentCurrencyCode
Definition: Code allocated to a currency, by a maintenance agency, under an international identification
scheme as described in the latest edition of the international standard ISO 4217 "Codes for the
representation of currencies and funds". Valid currency codes are registered with the ISO 4217
Maintenance Agency, and consist of three contiguous letters.
Type: CodeSet
Format
pattern [A-Z]{3,3}
Is restricted by
ActiveCurrencyCode on page 202, ActiveOrHistoricCurrencyCode on page 202
2.2.3.60 PreferredContactMethod1Code
Definition: Preferred method used to reach the individual contact within an organisation.
225
Standards MX
Type: CodeSet
Restricts
PreferredContactMethodCode on page 226
2.2.3.61 PreferredContactMethodCode
Definition: Preferred method used to reach the individual contact within an organisation.
Type: CodeSet
Is restricted by
PreferredContactMethod1Code on page 225
2.2.3.62 Priority2Code
Definition: Specifies the priority level of an event.
Type: CodeSet
Restricts
PriorityCode on page 227
2.2.3.63 Priority3Code
Definition: Specifies the priority level of an event.
Type: CodeSet
Restricts
PriorityCode on page 227
2.2.3.64 PriorityCode
Definition: Specifies the priority level of an event.
Type: CodeSet
Is restricted by
Priority2Code on page 226, Priority3Code on page 227
2.2.3.65 RegulatoryReportingType1Code
Definition: Identifies whether the regulatory reporting information applies to the debit side, to the credit
side or to both debit and credit sides of the transaction.
Type: CodeSet
Restricts
RegulatoryReportingTypeCode on page 228
227
Standards MX
2.2.3.66 RegulatoryReportingTypeCode
Definition: Identifies whether the regulatory reporting information applies to the debit side, to the credit
side or to both debit and credit sides of the transaction.
Type: CodeSet
Is restricted by
RegulatoryReportingType1Code on page 227
2.2.3.67 RemittanceLocationMethod2Code
Definition: Specifies the method used to deliver the remittance advice information.
Type: CodeSet
Restricts
RemittanceLocationMethodCode on page 228
2.2.3.68 RemittanceLocationMethodCode
Definition: Specifies the method used to deliver the remittance advice information.
Type: CodeSet
Is restricted by
RemittanceLocationMethod2Code on page 228
2.2.3.69 SettlementMethod1Code
Definition: Specifies the method used to settle the credit transfer instruction.
Type: CodeSet
Restricts
SettlementMethodCode on page 229
2.2.3.70 SettlementMethodCode
Definition: Specifies the method used to settle the payment instruction.
Type: CodeSet
229
Standards MX
Is restricted by
SettlementMethod1Code on page 229
2.2.3.71 TaxRecordPeriod1Code
Definition: Specifies the period related to the tax payment.
Type: CodeSet
Restricts
TaxRecordPeriodCode on page 231
2.2.3.72 TaxRecordPeriodCode
Definition: Specifies the period related to the tax payment.
Type: CodeSet
231
Standards MX
Is restricted by
TaxRecordPeriod1Code on page 230
2.2.4 Date
2.2.4.1 ISODate
Definition: A particular point in the progression of time in a calendar year expressed in the YYYY-MM-
DD format. This representation is defined in "XML Schema Part 2: Datatypes Second Edition - W3C
Recommendation 28 October 2004" which is aligned with ISO 8601.
Type: Date
2.2.5 DateTime
2.2.5.1 ISODateTime
Definition: A particular point in the progression of time defined by a mandatory date and a mandatory
time component, expressed in either UTC time format (YYYY-MM-DDThh:mm:ss.sssZ), local time
with UTC offset format (YYYY-MM-DDThh:mm:ss.sss+/-hh:mm), or local time format (YYYY-MM-
DDThh:mm:ss.sss). These representations are defined in "XML Schema Part 2: Datatypes Second
Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601.
Decimal fractions of seconds may be included. In this case, the involved parties shall agree on the
maximum number of digits that are allowed.
Type: DateTime
2.2.6 IdentifierSet
2.2.6.1 AnyBICDec2014Identifier
Definition: Code allocated to a financial or non-financial institution by the ISO 9362 Registration
Authority, as described in ISO 9362: 2014 - "Banking - Banking telecommunication messages -
Business identifier code (BIC)".
Type: IdentifierSet
Identification scheme: SWIFT; AnyBICIdentifier
Format
pattern [A-Z0-9]{4,4}[A-Z]{2,2}[A-Z0-9]{2,2}([A-Z0-9]{3,3}){0,1}
Constraints
• AnyBIC
Only a valid Business identifier code is allowed. Business identifier codes for financial or non-
financial institutions are registered and published by the ISO 9362 Registration Authority in the ISO
directory of BICs, and consists of eight (8) or eleven (11) contiguous characters.
Error handling:
2.2.6.2 BICFIDec2014Identifier
Definition: Code allocated to a financial institution by the ISO 9362 Registration Authority as described
in ISO 9362: 2014 - "Banking - Banking telecommunication messages - Business identifier code (BIC)".
Type: IdentifierSet
Identification scheme: SWIFT; BICIdentifier
Format
pattern [A-Z0-9]{4,4}[A-Z]{2,2}[A-Z0-9]{2,2}([A-Z0-9]{3,3}){0,1}
Constraints
• BICFI
Valid BICs for financial institutions are registered and published by the ISO 9362 Registration
Authority in the ISO directory of BICs, and consist of eight (8) or eleven (11) contiguous characters.
Error handling:
233
Standards MX
2.2.6.3 IBAN2007Identifier
Definition: The International Bank Account Number is a code used internationally by financial
institutions to uniquely identify the account of a customer at a financial institution as described in the
2007 edition of the ISO 13616 standard "Banking and related financial services - International Bank
Account Number (IBAN)" and replaced by the more recent edition of the standard.
Type: IdentifierSet
Identification scheme: National Banking Association; International Bank Account Number (ISO 13616)
Format
pattern [A-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}
Constraints
• IBAN
A valid IBAN consists of all three of the following components: Country Code, check digits and
BBAN.
Error handling:
2.2.6.4 LEIIdentifier
Definition: Legal Entity Identifier is a code allocated to a party as described in ISO 17442 "Financial
Services - Legal Entity Identifier (LEI)".
Type: IdentifierSet
Identification scheme: Global LEI System; LEIIdentifier
Format
pattern [A-Z0-9]{18,18}[0-9]{2,2}
2.2.6.5 UUIDv4Identifier
Definition: Universally Unique IDentifier (UUID) version 4, as described in IETC RFC 4122 "Universally
Unique IDentifier (UUID) URN Namespace".
Type: IdentifierSet
Identification scheme: RFC4122; UUIDv4
Format
pattern [a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12}
2.2.7 Indicator
2.2.7.1 BatchBookingIndicator
Definition: Identifies whether the sending party requests a single debit or credit entry per individual
transaction or a batch entry for the sum of the amounts of all transactions.
Type: Indicator
Meaning When True: Identifies that a batch entry for the sum of the amounts of all transactions in the
batch or message is requested.
Meaning When False: Identifies that a single entry for each of the transactions in the batch or message
is requested.
2.2.7.2 TrueFalseIndicator
Definition: A flag indicating a True or False value.
Type: Indicator
Meaning When True: True
Meaning When False: False
2.2.8 Quantity
2.2.8.1 DecimalNumber
Definition: Number of objects represented as a decimal number, for example 0.75 or 45.6.
Type: Quantity
Format
totalDigits 18
fractionDigits 17
2.2.8.2 Number
Definition: Number of objects represented as an integer.
Type: Quantity
Format
totalDigits 18
fractionDigits 0
2.2.9 Rate
2.2.9.1 BaseOneRate
Definition: Rate expressed as a decimal, for example, 0.7 is 7/10 and 70%.
Type: Rate
235
Standards MX
Format
totalDigits 11
fractionDigits 10
baseValue 1.0
2.2.9.2 PercentageRate
Definition: Rate expressed as a percentage, that is, in hundredths, for example, 0.7 is 7/10 of a percent,
and 7.0 is 7%.
Type: Rate
Format
totalDigits 11
fractionDigits 10
baseValue 100.0
2.2.10 Text
2.2.10.1 Exact2NumericText
Definition: Specifies a numeric string with an exact length of 2 digits.
Type: Text
Format
pattern [0-9]{2}
2.2.10.2 Exact4AlphaNumericText
Definition: Specifies an alphanumeric string with a length of 4 characters.
Type: Text
Format
pattern [a-zA-Z0-9]{4}
2.2.10.3 Max10Text
Definition: Specifies a character string with a maximum length of 10 characters.
Type: Text
Format
minLength 1
maxLength 10
2.2.10.4 Max128Text
Definition: Specifies a character string with a maximum length of 128 characters.
Type: Text
Format
minLength 1
maxLength 128
2.2.10.5 Max140Text
Definition: Specifies a character string with a maximum length of 140 characters.
Type: Text
Format
minLength 1
maxLength 140
2.2.10.6 Max15NumericText
Definition: Specifies a numeric string with a maximum length of 15 digits.
Type: Text
Format
pattern [0-9]{1,15}
2.2.10.7 Max16Text
Definition: Specifies a character string with a maximum length of 16 characters.
Type: Text
Format
minLength 1
maxLength 16
2.2.10.8 Max2048Text
Definition: Specifies a character string with a maximum length of 2048 characters.
Type: Text
Format
minLength 1
maxLength 2048
237
Standards MX
2.2.10.9 Max34Text
Definition: Specifies a character string with a maximum length of 34 characters.
Type: Text
Format
minLength 1
maxLength 34
2.2.10.10 Max350Text
Definition: Specifies a character string with a maximum length of 350 characters.
Type: Text
Format
minLength 1
maxLength 350
2.2.10.11 Max35Text
Definition: Specifies a character string with a maximum length of 35 characters.
Type: Text
Format
minLength 1
maxLength 35
2.2.10.12 Max4Text
Definition: Specifies a character string with a maximum length of 4 characters.
Type: Text
Format
minLength 1
maxLength 4
2.2.10.13 Max70Text
Definition: Specifies a character string with a maximum length of 70characters.
Type: Text
Format
minLength 1
maxLength 70
2.2.10.14 PhoneNumber
Definition: The collection of information which identifies a specific phone or FAX number as defined by
telecom services.
It consists of a "+" followed by the country code (from 1 to 3 characters) then a "-" and finally, any
combination of numbers, "(", ")", "+" and "-" (up to 30 characters).
Type: Text
Format
pattern \+[0-9]{1,3}-[0-9()+\-]{1,30}
2.2.11 Time
2.2.11.1 ISOTime
Definition: A particular point in the progression of time in a calendar day expressed in either UTC time
format (hh:mm:ss.sssZ), local time with UTC offset format (hh:mm:ss.sss+/-hh:mm), or local time format
(hh:mm:ss.sss). These representations are defined in "XML Schema Part 2: Datatypes Second Edition -
W3C Recommendation 28 October 2004" which is aligned with ISO 8601.
Decimal fractions of seconds may be included. In this case, the involved parties shall agree on the
maximum number of digits that are allowed.
Type: Time
2.2.12 Year
2.2.12.1 ISOYear
Definition: Year represented by YYYY (ISO 8601).
Type: Year
239
Standards MX
Legal Notices
Copyright
SWIFT © . All rights reserved.
You may copy this publication within your organisation. Any such copy must include these legal notices.
Confidentiality
This publication may contain SWIFT or third-party confidential information. Do not disclose this
publication outside your organisation without the prior written consent of SWIFT.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest
available version.
SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement
SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR Policy
- End-User License Agreement available at www.swift.com > About SWIFT > Legal > SWIFT Standards
IPR Policy.
Translations
The English version of SWIFT documentation is the only official version.