Regarding the Unstructured remittance information field, we have the following questions:
- Why is this an array?
The VOP API Work Block decided to keep the ISO 20022 definition and defined an array but only one entry is allowed. - What is the purpose/use? Is it comparable to SRD in UK?
The “Unstructured Remittance” may be used to transport the additional information (AT-C007) about AT-C001(payment account number of the payment counterparty) sent by the requester. This information is related to sub-account. - What does the end-to-end flow look like? To give some more context: The responding PSP will know that it needs the data to determine the correct account holder for matching, the PSU will know to provide it, but how is it governed that the requesting PSP knows that it should be forwarded/used in the VOP request?
The relation PSU-PSP is outside the scope of the VOP API, which focuses on the Inter-PSP space. How should the optional unstructuredRemittanceInformation field and the INACNO option in EDS be used?
The optional unstructuredRemittanceInformation field (also referred to as Secondary Reference/SRD) in the VOP API requests can be used to provide to the Responding PSP additional information that can be of added value for the Responding PSP in formulating its response to the VOP request message. This additional information may represent or relate to a sub-account held by the intended payee itself.It is then up to the Responding PSP to assess whether this additional information can be of added value in formulating its response to the VOP request message, and to define how the handle the matching process and how to determine its results (see more detailed information about the purpose of this field in FAQ: #27271)
Even though the INACNO option ("Support for additional information about payment account number"), is present in the EDS, neither the VOP scheme rulebook nor the VOP API Specifications state that a validation should be done on this option and that the unstructuredRemittanceInformation field cannot be sent when the Responding PSP has not configured the INACNO option in the EDS.
In addition, in the YAML file of the VOP API it is defined that empty strings are technically allowed.
- All text definitions (Max35Text, Max70Text, Max140Text, Max256Text, Max500Text) have “minLength: 0”, meaning that the empty string “” is syntactically valid.
The YAML contains a business rule that says, “only one entry may be used”.
Therefore, it is recommended to ignore the INACNO option in the EDS.
As the unstructuredRemittanceInformation field is optional in the VOP API requests, the Responding PSPs/RVMs cannot reject a VOP request that contains this field even if the Responding PSP has not configured the INACNO option in the EDS.
Moreover, the Responding PSPs/RVMs can also not reject a VOP request that contains an empty unstructuredRemittanceInformation field.To avoid any confusion, this will be further clarified in the next version of the VOP scheme rulebook (and related documents), and this option will be removed from the EDS.