Real Time Notification Additional Information

RTN FAQs and NPP Payment Return Codes

NPP RTN User Acceptance Testing Scenarios

Question

What UAT scenarios does ANZ recommend a customer complete prior to activating the NPP Real Time Notification service?

Answer

Using the Fileactive Self Service Testing API it is recommended a customer complete the following testing scenarios.

# Scenario Description RTN Self-Service Request NPP Payment Notification Response Snipet
1 ARM customer receipt The Corporate Customer is configured with an ARM account and receives a payment to their virtual account
  {
    "account_identification": "014814800000010",
    "entry_reference": "Trading transfer",
    "amount": "100.50",
    "debtor_name": "Andras Arato",
    "creditor_name": "Holden Holdings",
    "arm_creditor_account_identification": "063678965323010",
    "remittance_information": {
      "unstructured": [
        "Testing ARM Customer"
      ]
    }
  }
    
  {
    "identification": "D942DD0B23674C3FBDC2702ECB0C837F",
    "creation_date_time": "2022-07-27T23:44:01.9842888+00:00",
    "account_identification": "014814800000010",
    "account_issuer": "014814",
    "entry": [
      {
        "related_parties": {
          "creditor_account_identification": "965323010",
          "creditor_account_issuer": "063678"
        }
      }
    ]
  }
    
2 Non-ARM customer receipt The Corporate Customer receives a payment to their settlement account.
  {
    "account_identification": "014814800000010",
    "entry_reference": "Bill payment",
    "amount": "200.25",
    "debtor_name": "Andras Arato",
    "creditor_name": "Holden Holdings",
    "remittance_information": {
      "unstructured": [
        "Testing Non-ARM Customer"
      ]
    }
  }
    
  {
    "identification": "D942DD0B23674C3FBDC2702ECB0C837F",
    "creation_date_time": "2022-07-27T23:44:01.9842888+00:00",
    "account_identification": "014814800000010",
    "account_issuer": "014814",
    "entry": [
      {
        "related_parties": {
          "creditor_account_identification": "800000010",
          "creditor_account_issuer": "014814"
        }
      }
    ]
  }
    
3 Remittance information with emojis - binary Include any emoji in the remittance information
  {
    "account_identification": "014814800000010",
    "entry_reference": "Bill payment",
    "amount": "10.50",
    "debtor_name": "Andras Arato",
    "creditor_name": "Holden Holdings",
    "remittance_information": {
      "unstructured": [
        " πŸ˜€πŸš€ Testing with emojis"
      ]
    }
  }
    
  {
    "identification": "D942DD0B23674C3FBDC2702ECB0C837F",
    "creation_date_time": "2022-07-27T23:44:01.9842888+00:00",
    "account_identification": "014814800000010",
    "account_issuer": "014814",
    "entry": [
      {
        "remittance_information": {
          "unstructured": [
            "😀🚀 Testing with emojis"
          ]
        }
      }
    ]
  }
    
4 Remittance information with emojis - NCR HEX code points Include any emoji in the remittance information
  {
    "account_identification": "014814800000010",
    "entry_reference": "Bill payment",
    "amount": "10.50",
    "debtor_name": "Andras Arato",
    "creditor_name": "Holden Holdings",
    "remittance_information": {
      "unstructured": [
        "🛸 TC-04 testing emoji"
      ]
    }
  }
    
  {
    "identification": "D942DD0B23674C3FBDC2702ECB0C837F",
    "creation_date_time": "2022-07-27T23:44:01.9842888+00:00",
    "account_identification": "014814800000010",
    "account_issuer": "014814",
    "entry": [
      {
        "remittance_information": {
          "unstructured": [
            "🛸 TC-04 testing emoji"
          ]
        }
      }
    ]
  }
    
5 Pay ID - Mobile The payer/debtor has used a Pay ID when making the payment to the Corporate Customer's account.
  {
    "account_identification": "014814800000010",
    "entry_reference": "Bill payment",
    "amount": "150.00",
    "debtor_name": "Andras Arato",
    "creditor_name": "Holden Holdings",
    "creditor_alias": {
      "type": "TELI",
      "identification": "+61403736550"
    },
    "remittance_information": {
      "unstructured": [
        "Testing with PayId"
      ]
    }
  }
    
  {
    "identification": "D942DD0B23674C3FBDC2702ECB0C837F",
    "creation_date_time": "2022-07-27T23:44:01.9842888+00:00",
    "account_identification": "014814800000010",
    "account_issuer": "014814",
    "entry": [
      {
        "related_parties": {
          "creditor_account_proxy": {
            "proxy_type": "TELI",
            "proxy_identification": "+61403736550"
          }
        }
      }
    ]
  }
    
6 Pay ID - eMail The payer/debtor has used a Pay ID when making the payment to the Corporate Customer's account.
  {
    "account_identification": "014814800000010",
    "entry_reference": "Bill payment",
    "amount": "150.00",
    "debtor_name": "Andras Arato",
    "creditor_name": "Holden Holdings",
    "creditor_alias": {
      "type": "EMAL",
      "identification": "npp@mail.com"
    },
    "remittance_information": {
      "unstructured": [
        "Testing with PayId"
      ]
    }
  }
    
  {
    "identification": "D942DD0B23674C3FBDC2702ECB0C837F",
    "creation_date_time": "2022-07-27T23:44:01.9842888+00:00",
    "account_identification": "014814800000010",
    "account_issuer": "014814",
    "entry": [
      {
        "related_parties": {
          "creditor_account_proxy": {
            "proxy_type": "EMAL",
            "proxy_identification": "npp@mail.com"
          }
        }
      }
    ]
  }
    
7 Return of Funds (PACS.004) The Corporate Customer is receiving a credit to their settlement account.
  {
    "account_identification": "014814800000010",
    "entry_reference": "Bill payment",
    "amount": "500.00",
    "debtor_name": "Andras Arato",
    "creditor_name": "Holden Holdings",
    "remittance_information": {
      "unstructured": [
        "Testing Return of Funds"
      ]
    },
    "return_information": {
      "reason_code": "NARR",
      "additional_information": [
        "Beneficiary is",
        "unknown"
      ]
    }
  }
    
  {
      "identification": "D942DD0B23674C3FBDC2702ECB0C837F",
      "creation_date_time": "2022-07-27T23:44:01.9842888+00:00",
      "account_identification": "014814800000010",
      "account_issuer": "014814",
      "entry": [
        {
          "return_information": {
              "reason": {
                "code": "NARR"
              },
              "additional_information": [
                "Beneficiary is",
                "unknown"
              ]
            }
          }
        }
      ]
    }
    
8 Duplicate Check ANZ to reposcess a previously sent Notification which the customer should not process. n/a ANZ will send a previously sent Notification which has the same account_servicer_reference.
9 Invalid API Key ANZ to update customer Notificaiton profile with incorrect API Key. Customer to reject Notifications with invalid API key. Send a valid RTN request ANZ will send a well formed Notification which customer should reject with HTTP 401

NPP Emoji Handling

Question

How are emoji’s represented in NPP ?
NPP has a 280 character requirement for payment description (narrative), does this mean 280 emoji’s?

Answer

An emoji character is represented by one or more code points, when the encoding is UTF-8
A character in UTF-8 is a β€œcode point”, therefore in NPP payments you must allow 280 code points.

What does a code point look like?

Taking the example of the β€œFamily: Man, Woman, Girl, Boy” emoji: πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦ https://emojipedia.org/family-man-woman-girl-boy/

The emoji consists of 7 code points:

# Code Point
1 πŸ‘¨ U+1F468
2 U+200D
3 πŸ‘© U+1F469
4 U+200D
5 πŸ‘§ U+1F467
6 U+200D
7 πŸ‘¦ U+1F466

Representing emoji’s in JSON

A code point can be represented in binary or using Numerical Character Reference (NCR), for the example the β€œFamily: Man, Woman, Girl, Boy” emoji:

- binary:         πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦
- NCR (hex):      👨‍👩‍👧‍👦
- NCR (decimal):  👨‍👩‍👧‍👦

Note, the recommended representation is NCR (hex), however some NPP participants have used binary and NCR (decimal). The recommendation is to send NCR (hex) and accept NCR (hex), NCR (decimal) and binary

Using the example of the NPP Real Time Notification schema, the unstructured array within the remittance_information object is:

          remittance_information:
            type: object
            properties:
              unstructured:
                type: array
                description: >-
                  Information supplied to enable the matching/reconciliation of an entry 
                  with the items that the payment is intended to settle, such as commercial 
                  invoices in an accounts' receivable system, in an unstructured form.
                items:
                  type: string
                  minLength: 1
                  maxLength: 140
                minItems: 1
                maxItems: 2

When aligned to the NPP limit of 280 characters this corresponds to two unstructured fields each being a maximum of 140 characters. This means a maximum of 280 code points can be supported. For example:

{
  "remittance_information": {
    "unstructured": [
      "abcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghij",
      "abcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghij"
    ]
  }
}

When using emoji’s the string length is calculated using code points, therefore the unstructured array element is restricted to 140 code points.

Sample JSON Emoji’s (NCR hex)
{
  "remittance_information": {
    "unstructured": [
      "👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦",
      "👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦"
    ]
  }
}
Sample JSON Emoji’s (NCR decimal)
{
  "remittance_information": {
    "unstructured": [
      "👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦",
      "👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦👨‍👩‍👧‍👦"
    ]
  }
}
Sample JSON Emoji’s (binary)
{
  "remittance_information": {
    "unstructured": [
      "πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦",
      "πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦"
    ]
  }
}

Mixing characters

Note the 280 character limit allows for any combination of UTF-8 characters, for example the following are all valid 280 code point narratives:

Mixed Narrative
δ½ ε₯½πŸ‘¨πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text δ½ ε₯½πŸ‘¨πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text
Mixed Narrative in NPP Real Time Notification

Note: Chinese characters also converted to NCR (hex)

{
  "remittance_information": {
    "unstructured": [
      "你好👨‍👩‍👧‍👦Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text",
      "你好👨‍👩‍👧‍👦Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text"
    ]
  }
}

NPP Payment Return Codes

Return Code Return Code Definition
AC01 Format of the account number specified is not correct
AC02 Debtor account number invalid or missing.
AC03 Wrong IBAN in SCT
AC04 Account number specified has been closed on the bank of account’s books
AC06 Account specified is blocked, prohibiting posting of transactions against it.
AC07 Creditor account number closed.
AC13 Debtor account type is missing or invalid
AC14 An agent in the payment chain is invalid.
AC15 Account details have changed.
AC16 Account is in sequestration.
AC17 Account is in liquidation.
AG01 Transaction forbidden on this type of account (formerly NoAgreement)
AG02 Bank Operation code specified in the message is not valid for receiver
AG07 Debtor account cannot be debited for a generic reason. Usage: Code value may be used in general purposes and as a replacement for AM04 if debtor bank does not reveal its customer’s insufficient funds for privacy reasons.
AGNT Agent in the payment workflow is incorrect.
AM01 Specified message amount is equal to zero
AM02 Specific transaction/message amount is greater than allowed maximum
AM03 Specified message amount is an non processable currency outside of existing agreement
AM04 Amount of funds available to cover specified message amount is insufficient.
AM05 Duplication
AM06 Specified transaction amount is less than agreed minimum.
AM07 Amount specified in message has been blocked by regulatory authorities.
AM09 Amount received is not the amount agreed or expected
AM10 Sum of instructed amounts does not equal the control sum.
ARDT Already returned original SCT
BE01 Identification of end customer is not consistent with associated account number, organisation ID or private ID.
BE04 Specification of creditor’s address, which is required for payment, is missing/not correct (formerly IncorrectCreditorAddress).
BE05 Party who initiated the message is not recognised by the end customer
BE06 End customer specified is not known at associated Sort/National Bank Code or does no longer exist in the books
BE07 Specification of debtor’s address, which is required for payment, is missing/not correct.
BE08 Returned as a result of a bank error.
BE10 Debtor country code is missing or invalid.
BE11 Creditor country code is missing or invalid.
BE16 Debtor or Ultimate Debtor identification code missing or invalid.
BE17 Creditor or Ultimate Creditor identification code missing or invalid.
CN01 Authorisation is cancelled.
CNOR Creditor bank is not registered under this BIC in the CSM
CNPC Cash not picked up by Creditor or cash could not be delivered to Creditor
CURR Currency of the payment is incorrect
CUST Cancellation requested by the Debtor. ONUS Return: Mistaken payment, Incorrect payee or Incorrect payment address
DNOR Debtor bank is not registered under this BIC in the CSM
DS28 Return following technical problems resulting in erroneous transaction.
DT01 Invalid date (eg, wrong settlement date)
DUPL ONUS Return: Incorrect amount
ED01 Correspondent bank not possible.
ED03 Balance of payments complementary info is requested
ED05 Settlement of the transaction has failed.
EMVL The card payment is fraudulent and was not processed with EMV technology for an EMV card.
ERIN The Extended Remittance Information (ERI) option is not supported.
FF03 Payment Type Information is missing or invalid. Generic usage if cannot specify Service Level or Local Instrument code.
FF04 Service Level code is missing or invalid.
FF05 Local Instrument code is missing or invalid
FF06 Category Purpose code is missing or invalid.
FF07 Purpose is missing or invalid.
FOCR Return following a cancellation request
FR01 Returned as a result of fraud.
FRTR Final response/tracking is recalled as mandate is cancelled.
G004 In a FIToFI Customer Credit Transfer: Credit to the creditor’s account is pending, status Originator is waiting for funds provided via a cover. Update will follow from the Status Originator.
MD01 No Mandate
MD02 Mandate related information data required by the scheme is missing.
MD05 Creditor or creditor’s agent should not have collected the direct debit.
MD06 Return of funds requested by end customer
MD07 End customer is deceased.
MS02 Reason has not been specified by end customer
MS03 Reason has not been specified by agent.
NARR Reason is provided as narrative information in the additional reason information.
NOAS No response from Beneficiary
NOCM Customer account is not compliant with regulatory requirements, for example FICA (in South Africa) or any other regulatory requirements which render an account inactive for certain processing.
NOOR Original SCT never received
PINL The card payment is fraudulent (lost and stolen fraud) and was processed as EMV transaction without PIN verification.
RC01 Bank Identifier code specified in the message has an incorrect format (formerly IncorrectFormatForRoutingCode).
RC07 Incorrrect BIC of the beneficiary Bank in the SCTR
RC08 ClearingSystemMemberidentifier is invalid or missing. Generic usage if cannot specify between debit or credit account.
RC11 Intermediary Agent is invalid or missing.
RF01 Transaction reference is not unique within the message.
RR01 Specification of the debtor’s account or unique identification needed for reasons of regulatory requirements is insufficient or missing
RR02 Specification of the debtor’s name and/or address needed for regulatory requirements is insufficient or missing.
RR03 Specification of the creditor’s name and/or address needed for regulatory requirements is insufficient or missing.
RR04 Regulatory Reason
RR05 Regulatory or Central Bank Reporting information missing, incomplete or invalid.
RR06 Tax information missing, incomplete or invalid.
RR07 Remittance information structure does not comply with rules for payment type.
RR08 Remittance information truncated to comply with rules for payment type.
RR09 Structured creditor reference invalid or missing.
RR11 Invalid or missing identification of a bank proprietary service.
RR12 Invalid or missing identification required within a particular country or payment type.
RUTA Return following investigation request and no remediation possible.
SL01 Due to specific service offered by the Debtor Agent
SL02 Due to specific service offered by the Creditor Agent
SL11 Whitelisting service offered by the Debtor Agent; Debtor has not included the Creditor on its β€œWhitelist” (yet). In the Whitelist the Debtor may list all allowed Creditors to debit Debtor bank account.
SL12 Blacklisting service offered by the Debtor Agent; Debtor included the Creditor on his β€œBlacklist”. In the Blacklist the Debtor may list all Creditors not allowed to debit Debtor bank account.
SL13 Due to Maximum allowed Direct Debit Transactions per period service offered by the Debtor Agent.
SL14 Due to Maximum allowed Direct Debit Transaction amount service offered by the Debtor Agent.
SP01 Payment is stopped by account holder.
SP02 Previously stopped by means of a stop payment advise.
SVNR The card payment is returned since a cash amount rendered was not correct or goods or a service was not rendered to the customer, e.g. in an e-commerce situation.
TM01 Associated message was received after agreed processing cut-off time.
TRAC Return following direct debit being removed from tracking process.
UPAY Payment is not justified.

SG FAST RTN User Acceptance Testing Scenarios

Question

What UAT scenarios does ANZ recommend a customer complete prior to activating the SG FAST Real Time Notification service?

Answer

Using the Fileactive Self Service Testing API it is recommended a customer complete the following testing scenarios.

# Scenario Description RTN Self-Service Request SG FAST Payment Notification Response Snipet
1 Virtual account customer receipt The Corporate Customer is configured with a virtual account and receives a payment to their virtual account
  {
    "account_identification": "800000010",
    "entry_reference": "Trading transfer",
    "amount": "100.50",
    "debtor_name": "Andras Arato",
    "creditor_name": "Holden Holdings",,
    "arm_creditor_account_identification": "965323010",
    "remittance_information": {
      "unstructured": [
        "Testing Virtual account Customer"
      ]
    }
  }
    
  {
   "identification": "D942DD0B23674C3FBDC2702ECB0C837F",
   "creation_date_time": "2022-07-27T23:44:01.9842888+00:00",
    "account_identification": "014814800000010",
   "account_issuer": "ANZBSGSXXXX",
    "entry": [
     {
       "related_parties": {
         "creditor_account_identification": "965323010",
         "creditor_account_issuer": "ANZBSGSXXXX"
      }
    }
  ]
}
    
2 Non-Virtual account customer receipt The Corporate Customer receives a payment to their settlement account.
  {
    "account_identification": "800000010",
    "entry_reference": "Bill payment",
    "amount": "200.25",
    "debtor_name": "Andras Arato",
    "creditor_name": "Holden Holdings",
    "remittance_information": {
      "unstructured": [
        "Testing Non-ARM Customer"
    ]
  }
}
    
  {
    "identification": "D942DD0B23674C3FBDC2702ECB0C837F",
    "creation_date_time": "2022-07-27T23:44:01.9842888+00:00",
    "account_identification": "800000010",
    "account_issuer": "ANZBSGSXXXX",
    "entry": [
      {
       "related_parties": {
          "creditor_account_identification": "800000010",
          "creditor_account_issuer": "ANZBSGSXXXX"
      }
    }
  ]
}
    
3 Duplicate Check ANZ to reprocess a previously sent Notification which the customer should not process n/a ANZ will send a previously sent Notification which has the same account_servicer_reference
4 Invalid API Key ANZ to update customer Notificaiton profile with incorrect API Key. Customer to reject Notifications with invalid API key Send a valid RTN request ANZ will send a well formed Notification which customer should reject with HTTP 40