Remittance information

[pvdbosch]

Standardize vocabulary and types for remittance information for credit transfers both structured as unstructured (NL: "(on)gestructureerde mededelingen").

Requested for e-box project, which has these types in v3.0 draft:

remittanceInformationUnstructured:
          type: string
          maxLength: 140
          description: Remittance Information Unstructured.
remittanceInformationStructured:
          $ref: "#/components/schemas/RemittanceInformationStructured"

    RemittanceInformationStructured:
      description: The sum of reference, type and issuer length shall be less of 280 characters.
      type: object
      required:
        - reference
      properties:
        reference:
          type: string
          description: Remittance Information Structured Reference
        type:
          type: string
          description: Remittance Information Structured Type
        issuer:
          type: string
          description: Remittance Information Structured Issuer

[pvdbosch]

doing a bit of research on remittance information, I found:

• the Belgian OGM/VCS 12-digit structured format: e.g. +++123/1234/12345+++
• an international "Extended Remittance Information" based on ISO 20022:
  • One occurrence of 140 characters of unstructured remittance information and Up to 999 occurrences of 280 characters of structured remittance information based on the ISO 20022 standard.
• an older European standard ISO 11649; but I think most moved on to the ERI standard

Sources:

• https://www.rox-e.net/blog-gestructureerde-mededeling/
• https://www.europeanpaymentscouncil.eu/what-we-do/sepa-payment-schemes/sepa-credit-transfer/extended-remittance-information-option
• mapping from Belgian OGM/VCS format: https://www.febelfin.be/sites/default/files/2019-04/aos-ogmvcs.pdf

[cyberjasse]

Hello @pvdbosch . After discussion with those who implements the payment data feature, only the Belgian OGM 12 digits standard is needed. Currently, they do not check if the separators are presents as long as the reference contains 12 digits . They check also the max length described in the draft which apparently comes from bank guidelines.

[pvdbosch]

OK, I'd hold of the standardization of the international ISO 20022 format then until there are concrete use cases for that.

A draft proposition for the BE formats, as input for discussion in the REST working groups:

BelgianRemittanceInformation:
  description: Remittance Information for credit transfers as supported by Belgian banks
  oneOf:
    - $ref: "#/components/schemas/BelgianRemittanceInformationUnstructured"
    - $ref: "#/components/schemas/BelgianRemittanceInformationStructured"

BelgianRemittanceInformationUnstructured:
  description: Unstructured Remittance Information as supported by Belgian banks
  type: string
  maxLength: 140

BelgianRemittanceInformationStructured:
  description: Structured Remittance Information in the Belgian OGM-VCS format
  type: string
  pattern: "^\\d{12}$"
  # Often formatted for display as +++ 3 digits / 4 digits / 5 digits / +++ (example: +++010/8068/17183+++)
  # The last 2 digits are check digits (modulo 97) of the first 10 digits, but if the result is 0, then the check digits are 97

[pvdbosch]

@MarcBruyland , could you put this issue on the agenda of next work group meeting?

[cyberjasse]

Hello @pvdbosch . Thank you for your draft. After a meeting with Bosa, It looks like I was wrong about a point in my previous comment. The payment information that is usually called structured in a payment form ( +++012/0123/012345+++ ) is actually to put in the remittanceInformationUnstructured. Its confusing but its apparently bank wording. And the BelgianRemittanceInformationStructured is to put the SEPA communication. remittanceInformationUnstructured is for human-to-machine communication while BelgianRemittanceInformationStructured is for machine-to-machine communication .

Then during the meeting we also discovered that the BelgianRemittanceInformationStructured is actually not used and so I would like to not put it in the API since its not used/needed/implemented .

So we finally need only the property to put the remittance info OGM/VCS 12-digit

[AsiBOSA]

Hello to all,

When we re-define PaymentData, we analysed KBC way of working, and we asked them to review the PaymentData definition. This means the PaymentData definition is really close to banking terms, and one example is "remittanceInformationUnstructured", respect the classic human readable "reference".

As scenarios foreseen, we had citizen payment (citizen to government institution) and enterprise payment (government institution to government institution). During the meeting with SMALS of 14/02/2023, it was clarified by them, the inexistence of enterprise payment (foreseen use case), and based on this we can remove the field remittanceInformationStructured (logically for supporting SEPA standard).

Indeed for the citizen payment, it was defined/used remittanceInformationUnstructured. Again, the name used it's a banking name, if the name creates confusion, feel free to change, but be carefully if in the future we need to add again the enterprise payment, we don't need to have a name collision, or a migration gift.

[pvdbosch]

Note that the draft BelgianRemittanceInformationStructured only describes the specific Belgian OGM-VCS structured messages (12 digits) while SEPA (European) transfers have more fields and less restrictions (just string). SEPA remittance information seems nowadays to be based on the ERI standard from which fields "issuer" (Issr), "type" (Cd) and "reference" (Ref) are most used.

Mapping from the OGM-VCS structured messages to the SEPA format is described in https://www.febelfin.be/sites/default/files/2019-04/aos-ogmvcs.pdf .

Belgif OpenAPI types could be created for both formats, and according to specific use case of an API (like e-box), the most appropriate type could be chosen. If an API only allows the Belgian 12-digit format and wants to enforce and document this, a BelgianRemittanceInformationStructured would be more appropriate, and if it allows any SEPA/ERI-compliant remittance information, another (more complex) OpenAPI type could be used for the SEPA/ERI structure.

[pvdbosch]

In the PSD2 payment initiation APIs offered by various Belgian banks, I can't find a clear indication:

• some offer only a 140-length or unlimited unstructured remittance information field ING
• some offer both unstructured and structured fields; unclear in which of them the OGM-VCS message should be put KBC Belfius, KeyTrade
• BeoBank has a specific BbaCreditorReferenceInformation with 12 digits

For APIs that want to enforce the use of a 12-digit Belgian OGM-VCS, use of name RemittanceInformationUnstructured is problematic:

• "RemittanceInformationUnstructured" typically allows free-text up to a 140-char, which is too broad
• there'd be a naming confusion for clients: 'OGM= overschrijving gestructureerde mededeling' and its values can be mapped to a structured remittance information in SEPA transfer metadata

I'm adding the "BelgianRemittanceInformation" declaration previously above to a WIP pull request for openapi-money; but awaiting broader validation in next WG meeting before merging. SPF Fin will try to gather more context info on this issue.

[pvdbosch]

Info from Wim Bonneux after the previous meeting:

“We gebruiken altijd de standaard nationale structurele melding voor onze betaalberichten.

Ook voor internationale zendingen blijft deze standaard behouden.“

Communication in a payment

BE standard:

normal communication: max 140 chars

structured communication: example +++001/8094/26074+++

SEPA standard: max 140 chars

Swift standard: 6*35 chars (tag 72)

[pvdbosch]

Proposition below for a property in fedvoc (French to be completed):

Name: remittanceInformation NL overschrijvingsinformatie FR information de virement

Definition: EN: Information provided with a remittance meant for its beneficiary. NL: Informatie bij een overschrijving bedoeld voor de ontvanger ervan.

Comment:

EN: For Belgian remittances, either an unstructured remittance information of 140 characters, or a structured one of 12 digits is used. The latter one is commonly represented as +++ 3 digits / 4 digits / 5 digits +++ (example: +++010/8068/17183+++) NL: Voor Belgische overschrijvingen wordt ofwel een ongestructureerde mededeling van 140 karakters of een gestructureerde mededeling van 12 cijfers gebruikt. Deze laatste wordt meestal weergegeven als +++ 3 cijfers / 4 cijfers / 5 cijfers +++ (voorbeeld: +++010/8068/17183+++)

inOpenAPI: yes

[MarcBruyland]

Fedvoc is updated. Issue can be closed according to decision taken in the workgroup of 2023-09-29.