Enhancement to support camt.052 and camt.054 file exchange for Intraday Transaction Data and Credit/Debit Statements

[simonmeyerm]

Contact Details

simon.meyer@six-group.com

Issue category

Enhancement

Issue description

The API currently supports JSON format for intraday transaction data but lacks the capability to exchange camt.052 reports (Intraday Transaction Data) in XML format, which is required for alignment with Swiss payment standards.

For full compliance with the standards, it could be discussed, if a dedicated endpoint camt.054 notifications should be included in the specification.

Issue reasoning

Swiss financial institutions and accounting software heavily rely on XML-based camt.052 and camt.054 formats as part of their payment standards. Currently, only JSON is supported for intraday data, limiting compatibility with XML systems. By adding camt.052 in XML, we ensure compliance with industry standards and provide broader usability for clients who require XML-based data exchange.

Additionally, some banks do not provide camt.053 statements with transaction details, if batch bookings are broken down externally. In this case the transaction details are provided via a separate camt.054 credit/debit statement. Considering this fact and tendency to get real time transaction information the integration of a dedicated camt.054 endpoint should be considered.
This would ensure that users can always retrieve the necessary transaction details for accurate reporting and accounting.

Request

The proposed change aims to add functionality to exchange camt.052 and camt.054 files through the API, either by introducing new endpoints or enhancing the existing camt.053 endpoint to include camt.052 and camt.054.

camt.052 - Intraday Transaction Reports:

• File Types: camt.052 offers the possibility to support the following file types:

  • Full: Contains the complete transaction history up to the point of file generation.
  • Incremental: Contains only the transactions since the last file was generated.

• Response Indicators: The response for camt.052 should include an element that specifies whether the file is a full or incremental update. Additionally, a query paramter could be added:

  • Query Parameter: Allow users to specify whether they want a full or incremental file via a query parameter (e.g., ?type=full or ?type=incremental).

• Time Element: Each camt.052 file response must include a timestamp indicating the exact time the file was generated, ensuring clarity on when the data was last updated.

• Endpoint Structure: The endpoints could have the following structure:

  • Account-specific reports: /iso20022/{accountId}/reports/{reportId}
  • Collection of reports across all accounts: /iso20022/reports/{reportId}

camt.054 - Credit/Debit Transaction Statements:

• Date & Identifier:
  The response for camt.054 files must include at least the date when the file was generated. Ideally, a unique identifier for each transaction should be included to enhance traceability. It will need to be clarified if such an identifier exists or if there is a standard for this within the current framework.

• Endpoint Structure: The endpoints could have the following structure:

  • Account-specific reports: /iso20022/{accountId}/notifications/{reportId}
  • Collection of reports across all accounts: /iso20022/notifications/{reportId}

Below are some proposed examples of how the endpoints could be structured, with screenshots illustrating the potential designs for these API interactions:

Endpoints highlevel:

Response schema camt.052 reports:

Response schema camt.054 notifications:

Response schema for unified endpoint for all iso20022 statements

Proposed change

Affected API's

AIS

Code of Conduct

• I agree to follow this project's Contribution Guidelines

[simonmeyerm]

I would like to point out, that including a dedicated camt.054 endpoint would only make sense for the exchange of credit/debit notifications, mainly for the following use cases:

• Instant payment advises
• Financial institutions, which are producing camt.053 account statements with external batch booking breakdown in camt.054

[svenbiellmann]

Meeting Notes 26.9.24

Simon has presented this issue and suggested to add to new endpoints of camt.052 and camt.054.

Camt.052

• Service User will request the list of new entries and retrieve them.
• Service Provider can provide incremental or full camt.052. This information will be provided to the Serivce User.
• The provision of camt.052 by Service Provider shall be mandatory.

The Pull Request will be prepared by @simonmeyerm and be discussed on next meeting.

Camt.054
At the present with no or few Instant Payment transactions the added value is moderate. In order to align JSON and XML and close the gap the inclusion of camt.052 in SFTI is recommended.

In the discussion has been highlighted by Thomas (bexio) that the detail of the transactions (Sammelbuchungsauflösung) needs to be provided either in the camt.053 or camt.054.

[svenbiellmann]

Meeting Notes 31.10.24

Camt.052
It was noticed that the new camt.052 endpoint differs due to request by accountId. This PR will be discussed at next meeting.

Camt.054
The Pull Request will be prepared by @simonmeyerm and discussed on next meeting.

[vpusher]

Since we might add more and features to the /iso20022 endpoint with time, shouldn't we move on a more flexible naming convention ? I have several proposition in mind:

• /iso20022/{accountId}/cashmanagement/52
• /iso20022/{accountId}/cashmanagement/52/{id}
  or
• /iso20022/{accountId}/camt/52
• /iso20022/{accountId}/camt/52/{id}
  or even
• /iso20022/{accountId}/camt/52/resources
• /iso20022/{accountId}/camt/52/resources/{id}

It makes very clear what kind of file we are working with + it avoids any future collision with words like "notification", "report", "statement" since ISO have hundreds of different file/message types. For example camt.088 is also a "report", as 081, 083, 084, etc...

[svenbiellmann]

Meeting Notes 12.12.24

Camt.052

• The structure is based on camt.053.
• Additionally, the attribute date with time stamp is extended.

Camt.054

• The objective is to enable the provision of "Sammelauflöser" and later on the advice for Instant Payment.
• The date range fromTo shall be added, analogously to the camt.053 with request.

General

• The structure for camt.052 and camt054 will be analogously to camt.053.

@simonmeyerm will adjust the Pull Request and provide an update when the Pull Request has been updated.

Action: The community shall check the updated Pull Request upfront to the next meeting on 16th January in order to prepare for upcoming discussion and decision.

[svenbiellmann]

Meeting Notes 16.1.25

The initial proposal would be to create new endpoints for camt.052 and camt.054. Latter will be used for banks that can not deliver camt.053 with details. Thomas (PoFi) advocates to unify all ISO message types (camt.052, camt.053, camt.054) into one endpoint. Olivier states that Berlin Group standards focuses on a different approach. It uses one endpoint but returns multiple camt types. Link to the Berlin Group specification

@simonmeyerm will check and adjust so that for V5 the endpoints camt.052 and camt.053 can be kept separated. Maybe on a later stage the endpoints can be merged and unified. When the changes on the API specs are completed, @simonmeyerm will provide the update directly to the community.