ISO20022 payments

Output Files

22min

When Unicorn has processed your payment instructions, it creates XML output files (PSRs) conforming to the ISO 20022 standard’s PAIN.002.001.03 format. The output files provide information about the status of your transactions within Cross River’s (CR) banking core, such as whether the transactions were accepted or rejected.

Whereas legacy banks send you an acknowledgment file followed by a PSR later on, Cross River sends you the PSR immediately. Cross River achieves this by having Unicorn deliver your payment instructions to Cross River's API-based core banking system.

For more information on status and error codes, see here.

Output file naming convention

The output file PSRs conform to the following naming convention:

{InputFileName}.{date}.{time}-{number}

where "number" is the ordinal number of file from the specified date and time, and is used to differentiate among multiple possible files that were generated at that date and time. If only one file was generated at that date and time, the value of "number" will be "1".

How an output file is built

The root element in the Output file is CstmrPmtStsRpt (Customer Payment Status Report) and it contains the following 3 building blocks:

  • GrpHdr that contains the file metadata.
  • OrgnlGrpInfAndSts contains message identifiers based on the original input file and includes a status for the group.
  • OrgnlPmtInfAndSts contains elements referencing the original transactions. This is an optional section that may appear multiple times in the file. It can contain an individual status for the original instruction, as well as elements from your original transaction file.

Here’s an example of the file structure:

XML


The Group Header

The GrpHdr block is a set of characteristics shared by all individual transactions included in the message. This building block is present once per output file. The group header includes the following elements:

XML

  • MsgId: Message ID. A unique ID that Unicorn generates for the file. It is unique per instructed party for a pre-agreed period. Best practice: Use a new for each file.**
  • CreDtTm: Created Date and Time. This is the date and time at which the output file was created by Unicorn.
  • InitgPty: Initiating Party. This element is used to indicate the party that initiated the file. With the output files this will always be CR. The InitgPty block appears as follows:
XML

  • Nm: Name used to identify the initiating party.
  • Id: The unique identifier for the initiating party.
  • OrgId: Organization Identification, containing the BICOrBEI code.
  • BICOrBEI: Business Identification Code. A unique and unambiguous identifier of the initiating party, which can be an organization or an individual person.

Original Group Information And Status

Various information can be included for the group in the OrgnlGrpInfAndSts block. The information included will depend on the input file and the status of the original transaction.

  • OrgnlMsgId is the message identification number from the original input file.
  • OrgnlMsgNmId indicates the original message type, and will either be pain.001.001.03 for payments (USD) or pain.008.001.02 for direct debits (USD).
  • OrgnlNbOfTxs shows the number of transactions in the original input file.
  • OrgnlCtrlSum displays the control sum from the original input file.
  • GrpSts indicates the status for a group of transactions. See here for details about the different statuses.
  • AddtlInf shows details for the status in the case of a rejected file. The rejection reason can be due to an issue with the original XML file, as well as an issue arising during internal processing by CR.

The original transaction file was accepted

The following example of the OrgnlGrpInfAndSts block shows that the original input transaction file was accepted. You can see this in the GrpSts element, where "ACTC" indicates the file was accepted.

XML


The original transaction file was rejected

The following example of the OrgnlGrpInfAndSts block shows that the original input transaction file was rejected. You can see this in the GrpSts element, where "RJCT" indicates the file was rejected. In this case, the output file will include the StsRsnInf element, which gives information about why the initial transaction was rejected. The reason will always be shown in the AddtlInf element.

If your original transaction file is rejected, you should correct any errors and resend it to CR.

In this example, the reason the file was rejected is shown as “Number of transactions in file does not match with control record: Expected 1, but calculated 2”. This means that there is a mismatch between the OrgnlCtrlSum provided in the original file and the actual number of transactions provided there.

XML


Original Payment Information And Status

OrgnlPmtInfAndSts is a third and optional block, which contains elements referencing the original transactions. It corresponds to the batch level in the original file (specifically the PmtInf block), and can also include individual statuses for the original instructions.

XML

  • OrgnlPmtInfId is a unique identifier, assigned by the original initiating party. It’s used to identify the original payment information block within the output file.
  • OrgnlNbOfTxs indicates the number of payments in the original payment information block.
  • OrgnlCtrlSum shows the sum total of all transactions included in the original payment information block.
  • PmtInfSts indicates the status of the payment information block as follows:

Payment Info Status

Meaning

ACTC

The batch was validated and authenticated successfully

RCVD

The batch is being checked

RJCT

The batch was rejected

PDNG

One or more transactions in the batch is pending

PART

The transaction batch was partially accepted and partially rejected. This means that the batch includes one or more rejected transactions as well as one or more transactions that have been accepted.

In the output file generated by Unicorn, you’ll be able to see which transactions were rejected so you can make the necessary changes and resend to CR.

If your original transaction file is rejected, you should correct any errors and resend to CR.

Transaction-level information

The output file can include information about individual instructions in the original file in a building block called TxInfAndSts. This will be included as part of the OrgnlPmtInfAndSts building block. The transaction-level information includes the following:

  • OrgnlInstrId contains the value of the Instruction Identification (InstrId) element provided in the input file. This element won’t be present if an InstrId value wasn’t provided in the input file.
  • OrgnlEndToEndId contains the value of the EndtoEndId element provided in the input file.
  • TxSts indicates the transaction status using one of the following codes:

Status

Meaning

ACPT

The transaction has been accepted by the external payment processor for processing

RJCT

The transaction was rejected

ASCS

The transaction has been completed and the settlement has been confirmed on the debtor's account

ACSP

The transaction was accepted and has been moved on for processing

PDNG

The transaction is pending and requires further processing

In addition, the TxInfAndSts block contains the following elements:

  • OrgnlTxRef: Contains information on the original transaction in its child elements, such as the transaction amount and the transaction's requested execution date.
  • Amt: Contains the amount of the original transaction in a child element.
  • InstdAmt: Contains the amount of the original transaction in the indicated currency.
  • ReqdExtnDt: Requested Execution Date. The date on which the originator's account was to be debited.

If the status is shown as RJCT (rejected) an additional element, StsRsnInf, will be included in the TxInfAndSts block. This will provide information on why the transaction was rejected.

Here’s an example of the TxInfAndSts building block for when a transaction has succeeded:

XML


Below is an example the TXInfAndSts building block for when a transaction has been rejected:

XML


The StsRsnInf block, which appears inside the TxInfAndSts block in the case of a rejected transaction, contains information on why the transaction was rejected, and contains the following elements:

  • Rsn: Contains the reason code in a child element.
  • Cd: Code. Currently, this code will always have the value of NARR, standing for "Narrative". The actual narrative text appears in the AddtlInf element.
  • AddtlInf: Shows details for the status in the case of a rejected file. The rejection reason can be due to an issue with the original XML file, as well as an issue arising during internal processing by CR.

Full sample output files

Sample output files (successful transaction)

The examples below shows full output files generated when Unicorn has successfully processed the transaction file, for both the pain.001.001.03 and pain.008.001.002 formats. These examples include the Group Header, Original Information And Status, and Original Payment Information And Status blocks.

Output example from pain.001.001.03 input file (successful transaction)

The following is an example output file corresponding to a pain.001.001.03 input file, generated when the processing of the transaction file has succeeded.

XML


Output example from pain.008.001.02 input file (successful transaction)

The following is an example output file corresponding to a pain.008.001.02 input file, generated when the processing of the transaction file has succeeded.

XML


Sample output files (rejected transaction file)

The examples below show full output files generated when the transaction file has been rejected.

In such output files, the error message information appears in the tag.

Rejected file (error on batch level)

The following example shows an output file generated when the transaction file has been rejected on the batch level, for an original file that came in pain.008.001.02 format.

XML


Rejected file (error on transaction level)

The following example shows an output file generated when the transaction file has been rejected on the transaction level, for an original file that came in pain.001.001.003 format.

XML




🤔
Have a question?
Our super-smart AI, knowledgeable support team and an awesome community will get you an answer in a flash.
To ask a question or participate in discussions, you'll need to authenticate first.



Updated 15 Oct 2024
Doc contributor
Did this page help you?