Overview

This section explains the functionality, payment scenario and implementation of Traceability Microservices . They are:

• It is possible to trace events from multiple third parties.
• It is tamper evident, that is, either the events in the service must have occurred as stated or it is evident that the service has been tampered with.
• It is easy to query the events for a TPP, a user, an ASPSP or a payment.
• All events in a payment exchange should be recorded, for instance for a payment request:
  • The quote for the payment (time, cost, exchange rate) (TPP to ASPSP)
  • The consent for the payment (PSU to ASPSP)
  • The payment order being received (TPP to ASPSP)
  • The credit transfer requested by the bank (ASPSP to Scheme)
  • The credit transfer response (Scheme to ASPSP)
  • The update to the user position (ASPSP to ASPSP)
  • The payment completion (ASPSP to TPP)
• The traceability is only needed for events that make changes, not for queries.
• No personally identifiable information (PII) stored in the traceability service
  NOTE: ISO 27000:2018 defines non-repudiation as the ability to prove the occurrence of a claimed event or action and its originating entities where an event is the occurrence or change of a particular set of circumstances.

Payment Scenario

If a Payment Service User (PSU) asks a Third-Party Payment Provider (TPP) to make a payment through an account servicing payment provider (ASPSP), usually the PSU’s bank, then it is possible that disputes occur. The TPP may deny a payment made by a bank, a bank may deny a request was made by a TPP, you may deny that consent was given to a payment and so on.

The aim of the traceability service is to demonstrate in a secure manner the actual sequence of events, or to show that there was tampering, that is, it should act as a forward secure log.

As either party may fake its log of events, there is a need for the system to be tamper evident, that is, either the log of events is trustworthy or it has evidently been tampered with. This is not the same as tamper proof. If there is a need for tamper proofing as well, then writing the traceability data to write-only storage on a secure server may be needed as well. This is outside the scope of this solution.

Traceability Implementation

This section explains how the log service integrates with the bank's system. Implementation of the traceability service requires a tamper evident, high performance, log that can be concurrently appended to, immediately notifies of improper changes, can be quickly queried for events, and can be quickly verified as intact by third parties using excerpts of the log. In addition, a secure store of the data for events is also needed to keep PII separate from the secure log, allowing it to be ‘forgotten’, but linked to the log by digital signatures providing non-repudiation of senders and receivers of messages as well as the content of messages.

The interaction diagram below shows how the log service integrates with the banks’ systems.

Where,

• PSU (Payment Service User) - This is a customer of both the bank and the third party payment provider.
• TPP (Third-Party Payment Provider) - This could be a merchant, FinTech or another bank.
• T24 (Temenos Transact) – This is a Temenos Core Banking product.
• Identity – This specifies the identity provider for the bank and this could be an Open ID Connect Provider.
• TPH – This is Temenos Payment Hub.
• Log – This is the log service for Traceability.
• CSM – This specifies the clearing and settlement mechanism, such as UK Faster Payments, Instant SEPA or CHAPS.