Table of contents
Reporting Flow
In order to enable the Creditors to reconcile the reversals that have occurred (ref.Reconciliation of remittance flow), the PSP that performed the transaction shall send to the Payment Node-SPC a reporting flow (RF) prepared in accordance with the scheme shown in Table 6.
This flow must be sent by, and no later than, midnight of the second business day following the receipt of the payment order (D+2).
The columns Lev, Type, Occ and Len of the above mentioned Table 6 take on the following meaning:
Table 5 - Reporting flow -Column description
| column | description |
|---|---|
| Lev. | indicates the level of indentation of the data in order to make evident the structures that contain additional information ("Gen" column equals s): e.g., level 1 structures are formed by all data above level 1, level 2 structures are formed by all data above level 2, and so on. |
| Type | indicates the type of the data to be used; it can take the following values:
|
| Occ | indicates the "occurrences" of the data in the format min..max. |
| Len | indicates the maximum length of the data item in the format min..max; in the case of a fixed length only the data item lenwill appear, in the case of fixed lengths alternatively the notation will be len1 / len2. |
Table 6 - Reporting flow - Data Scheme
| Datum | Lev. | Type | Occ | Len | Content |
|---|---|---|---|---|---|
| Objectversion | 1 | an | 1..1 | 1..16 | Version that identifies the object exchanged. Allowed values: “1.0” and “1.1” |
| Flowidentifier | 1 | an | 1..1 | 1..35 | Identifier associated with the generation and transmission of the remittance flow. Must be univocal within the reference year of the payment transactions to which the flow refers. |
| dateTimeFlow | 1 | an | 1..1 | 19 | It indicates the date and time of creation of the flow, according to ISO 8601 format [YYYY]-[MM]-[DD]T[hh]:[mm]:[ss] |
| SettlementUnivocalidentifier | 1 | an | 1..1 | 1..35 | Reference assigned by the PSP to the funds transfer transaction by which the remittance of the collected amounts or the accumulation of the credits made by customers is settled in accounting terms. |
| Settlementdate | 3 | an | o | 10 | Indicates the execution date of the funds transfer transaction by which the remittance of the collected amounts is settled in the accounts, in the format ISO 8601 [YYYY]-[MM]-[DD]. |
| SenderInstitution | 1 | s | 1..1 | Aggregation related to the sender PSP that generates this flow. | |
| UnivocalidentifierSender | 2 | s | 1..1 | Aggregation reporting information concerning the identification of the sender institution of the flow. | |
| UnivocalIdentifiertype | 3 | an | 1..1 | 1 | Alphanumeric field describing the coding used to identify the Sender Institution; if present, it can take the following values:
|
| UnivocalIdentifiercode | 3 | an | 1..1 | 1..35 | Alphanumeric field that can contain the fiscal code or VAT no., ABI code or BIC code of the sender PSP, depending on the given Univocalidentifiertype. |
| Sendername | 2 | an | 0..1 | 1..70 | Contains the name of the sender PSP generating the flow. |
| RemittingBankBICcode | 2 | an | 0..1 | 1..35 | Contains the BIC code of the PSP that generated the SEPA Credit Transfer remittance. Corresponds to the AT-09 data element of the SCT. |
| Receiverinstitution | 1 | s | 1..1 | Aggregation relating to the recipient Creditor of the flow. | |
| ReceiverUnivocalIdentifier | 2 | s | 1..1 | Aggregation reporting information concerning the fiscal identification of the Creditor receiving the flow. | |
| UnivocalIdentifiertype | 3 | an | 1..1 | 1 | Alphanumeric field indicating the nature of the Creditor; if present it must take the value ‘G’, Legal Person Tax Identifier. . |
| UnivocalIdentifiercode | 3 | an | 1..1 | 1..35 | Alphanumeric field containing the fiscal code of the flow recipient Creditor. |
| Receivername | 2 | an | 0..1 | 1..70 | Contains the name of the Creditor that receives the flow. |
| TotalNumberPayments | 1 | n | 1..1 | 1..15 | Number of payments present in the flow. |
| TotalAmountPayments | 1 | n | 1..1 | 1..18 | Total amount of payments present in the flow. Must coincide with the sum of the singleAmountPaid data present in the flow. It must be greater than 0. |
| SinglePaymentsdata | 1 | s | 1 n | Aggregation with a number of occurrences equal to the element TotalNumberPayments. | |
| PaymentUnivocalIdentifier | 2 | an | 1..1 | 1..35 | Returns the IUV code value to which the payment reported in the flow refers. |
| CollectionUnivocalIdentifier | 2 | an | 1..1 | 1..35 | Univocal transaction reference, it is represented by the payment token. |
| SinglePaymentDataindex | 2 | n | 0..1 | 1 | Index of the occurrence of the payment within the transfer structure , Transferidfield . |
| singleAmountPaid | 2 | an | 1..1 | 3..12 | Numeric field indicating the amount paid or revoked. It must be different from 0. Where the single amount paid refers to a revoked payment (given codeSinglePaymentEvent =3) it must take a negative value. |
| SinglePaymentOutcomecode | 2 | n | 1..1 | 1 | Numeric field indicating the outcome of the payment. It can have the following values:
|
| SinglePaymentOutcomedate | 2 | an | 1..1 | 10 | Indicates the date on which the payment was ordered or revoked, in the format ISO 8601 [YYYY]-[MM]-[DD]. |
As far as the Creditors are concerned, these homogeneous data flows are made available to them through the infrastructure referred to in Article 5, paragraph 2 of the CAD to which the PSPs making the remittance are required to connect, in the manner set out in the SANPs (Annex B to the Guidelines).
The XML schema (XSD) describing the content of the XML files used to transfer the information of the reporting flow is provided in electronic format in the GitHub pagopa-api repository (https://github.com/pagopa/pagopa-api/blob/master/general/FlussoRiversamento_1_0_4.xsd).
Finally, it should be noted that since the reporting flow is associated with a single remittance SCT, said flow is obviously always related to a single IBAN crediting code.
The preparation of more than one RF with the same identifierFlow is an exceptional event, which can be motivated by errors present in the previous flow, such an operation must be managed in the manner described in the section "Management of overwriting Reporting Flowse" present in the SANPs.
Clarifications on the "content" column of Table 6 - Reporting Flow - Data Template.
Bearing in mind that the meaning of the data required for the reporting flow is given in the "content" column of Table 6, some clarifications useful to Creditors on the data in the reporting flow are provided below:
- Flowidentifier: must be the same as the one reported in the <Flowidentifier> component of the SEPA Remittance Credit Transfer description (“Remittance Information” - attribute AT-05, Fund transfer operation);
- SettlementUnivocalidentifier Transaction Reference Number (TRN) AT-43 Originator Bank’s Reference of the SEPA Remittance Credit Transfer;
- CollectionUnivocalIdentifier: represents the identifier by which the PSP identifies the individual transaction, it is contained within the receipt element receiptId;
- SinglePaymentDataindex: optional data element representing the i-th occurrence of payment within the reported receipt;
Standardization of the FlowIdentifier element.
In order to standardize the way of composition of the FlowIdentifier element present in the standardized description of the SEPA Credit Transfer and also in the reporting flow, the following structure is adopted:
<settlement date><sender institution>"-"<flow>.
where the above components take on the following meaning:
- <settlement date> contains the same information as the Settlementdate element of the XML file;
- <sender institution> contains the identification code within the platform of the PSP preparing the flow;
- "-" fixed data;
- <flow> alphanumeric string that, together with the above information, allows the flow itself to be uniquely identified. The characters allowed within the string are: digits 0 to 9, upper and lower case letters of the Latin alphabet, and the characters in Table 7.
Table 7 - Allowed characters
| ASCII | Symbol | Name | |
| Dec | Hex | |||
| 45 | 2D | - | minus sign - hyphen |
| 95 | 5F | _ | underscore |
Examples:
2015-07-15xxxxxxxx-0000000001
2015-07-15xxxxxxxx-hh_mm_ss_nnn
Tell us what you think
For clarifications on implementation specifications, such as SACI and SANP, you can open an issue on GitHub