MESSAGE acmt.023 Identification Verification Request

The acmt.023 message is used for:

  • (a) proxy resolution requests and

  • (b) account resolution requests.

The messages for both use cases are very similar, with only slightly different information being provided.

For further detail on each element in the acmt.023 and acmt.024, please refer to the Message Guidelines (Excel).

Structure of the acmt.023 Identification Verification Request V03

The acmt.023 message has two main blocks:

  • Assignment contains information about who is making the request and where that request should be sent:

    • Creator describes the Sender of the payment, who is initiating the proxy/account resolution request prior to sending a payment instruction

    • First Agent and Assigner both describe the Source PSP, acting on behalf of the Creator (Sender)

    • Assignee describes the entity that the request is assigned to. Depending on the local implementation, this will initially be set to the Source IPSO or Source Proxy Directory Operator (S-PDO).

    • The element Assignee > Agent > PostalAddress > Country must be set to the Destination Country as selected by the Sender. (This helps Nexus to route the request to the appropriate proxy directory.)

    • Nexus will update the Assignee to the relevant Destination Proxy Directory Operator or Creditor Agent

  • Verification contains information about the proxy or account we are trying to verify

    • The PartyAndAccountIdentification > Account element contains one of the following:

      • An IBAN (PartyAndAccountIdentification > Account > Identification > IBAN)

      • An account ID (which must be accompanies by a Financial Institution Identifier in the Agent block) (PartyAndAccountVerification > Account > Identification > Other > Identification)

      • A ProxyId and ProxyType code (PartyAndAccountIdentification > Account > Proxy > Identification and PartyAndAccountIdentification > Account > Proxy > Type > Code )

    • In some cases (such as the Philippines) a proxy must be accompanied by the BIC of the financial institution in the Agent block. In this case, Nexus will include the BIC as one of the address inputs provided via the API call; the Source PSP does not need to implement custom logic for these cases).

The PartyAndAccountIdentification > Party block would be used for a Comparison model of verification, in which the Debtor has provided information about the Recipient, which can be sent to the Destination PSP. The Destination PSP will compare that information to the actual information they have on record, and reply either with a code that describes the degree of match, or with corrected information (assuming the original information was close enough). This model is not currently supported in Nexus, but may be developed in future.

Using acmt.023 for Proxy Resolution

  • The proxy provided by the Sender should be included in the Verification > PartyAndAccountIdentification > Account > Proxy element:

  • Type should include the ISO 20022 ExternalProxyAccountType1Code (eg MBNO) for the proxy type that was selected by the Sender. This code would have been provided by Nexus to the Source PSP when the Source PSP calls the GET /countries/{countryCode}/addressTypes option.

  • Identification should include the actual proxy value, as text, as provided by the Sender (as entered into the Source PSP’s app)

Uniquely identifying the Debtor: To allow the Proxy Directory Operator to guard against abuse (eg entering multiple phone numbers into a Nexus-enabled app in order to get the corresponding account holder names), the field Assignment > Creator > Party > Identification > PrivateIdentification > Other > Identification element should include a unique ID that uniquely identifies the Sender. To avoid sensitive data, this ID should ideally be a generated hash value that will be reused for all requests from this Sender. However, the Source PSP may instead provide an official ID (eg National Identity Number), an internal customer ID.

The PDO can (optionally) use this value to rate-limit the number of requests coming from a particular Sender. (This is recommended but not mandatory.)

Using acmt.023 for Account Resolution

  • The Account Identifier provided by the Sender should be included in the Verification > PartyAndAccountIdentification > Account element

  • IBANs are included in the Account > Id > IBAN element

  • Non-IBAN Account Identifiers should be given in the Account > Id > Other > Id element

  • The PSP / Financial Institution Identifier provided by the Sender should be included in the Verification > PartyAndAccountInformation > Agent section

    • If a BIC is used, it should be given in Agent > FinancialInstitutionIdentification > BICFI element

    • If a non-BIC Financial Institution Identifier is used,

      • The Financial Institution Identifier should be given in Agent > ClearingSystemMemberIdentification > MemberIdentification element

      • The Agent > FinancialInstitutionIdentification > ClearingSystemMemberIdentification > ClearingSystemIdentification > Code element should be filled with the IPSO’s ExternalClearingSystemIdentification1Code (from the ISO 20022 External Code Set)

IPSOs may not have requested an ExternalClearingSystemIdentification1Code in the ISO 20022 External Code Set. They will need to register a code before going live on Nexus.

Message transformation by Nexus

When an acmt.023 travels through Nexus, Nexus will update the Assignee as follows:

  • For proxy resolution requests, the Assignee will be updated to the relevant Destination IPS or Destination PDO depending on the local implementation OR

  • For account resolution requests, the Assignee will be updated to the Creditor Agent

No other transformations are made.

Last updated