Release Notes - Major Releases

1. Customer Credit Transfer (gCCT) Service:

   Improve end-customer cross-border payments experience.

2. Cover payments (gCOV) Service:

   Increase timely processing of gCCT payments when no direct account relationship between sender and receiver.

3. Stop & Recall (gSRP) Service:

   Immediately stop a payment, in case of fraud or error Stop request sent to bank processing gCCT.

Clients would be able to get the latest payment information provided by the GPI tracker. The main purpose of the GPI initiative is to improve customer experience, for example -

1. Faster, same-day use of funds (within the time zone of the receiving GPI customer)

2. Transparency of fees and exchange rates

3. Remittance Information transferred unaltered

4. End-to-end tracking from initiation to reception

’SWIFT global payments innovation (GPI) is designed to address the needs of both end-customers and financial institutions to keep track of their cross-border payments and have a clear visibility of events at each leg of the transaction. Financial institutions are also obliged to meet their compliance obligations and market, credit, and liquidity risk requirements at the earliest possible time.

For a few years, our product already sent universal confirmations (MT199) to GPI Tracker through the SWIFT network.

The platform will integrate with:

• GPI Tracker - SWIFT product allowing gCCT payments to be tracked end-to-end via the UETR and Service Type Identifier contained in the header of those payments. Interactions with the tracker can be done via files (both MT & MX) or APIs.

• GPI Directory - a complete listing of all GPI members and their capabilities provided by SWIFT.

With the above integration, our product would be able to provide the SWIFT GPI Mandatory Service.

The (GPI) customers need to comply with SWIFT onboarding requirements before implementation.

1. Clients need to subscribe to SWIFT GPI mandatory services which include SWIFT GPI Customer Credit Transfer (gCCT), SWIFT GPI Cover Payments (gCOV), and Stop and Recall (SRP).

2. Clients must be both gCCT Originating Agent and gCCT Creditor Agent.

3. Clients must need to register all their gCCT Live 11-character BIC in the (GPI) Directory.

4. Clients must establish RMA with the Tracker BIC. (Single RMA authorization covers both production and testing BIC since it is established at the TRCKCHZZ level.)

5. Clients need to subscribe to the SWIFT GPI network environment (Production, Test & Training, and Vendor testbed).

6. Clients need to be successfully onboarded with our product and configure the GPI services.

7. Clients are responsible for providing and maintaining their published GPI data (via GPI online data collection).

8. Clients are responsible for updating their configuration on our product when they update their information in the GPI Directory.

9. Appropriate bilateral agreement is in place to conduct their business and financial transactions using the gCCT and gCOV services.

10. Adherence to the GPI Customer's Roles and Responsibilities, obligations, business rules, and technical specifications as defined in the present rulebook.

Any outgoing Customer or Bank Transfers

• Our product would be able to identify whether the Customer or Bank Transfers would require a Cover Payment. If yes, we will help to generate it once the clients subscribe to the service.

NOSTRO enrichment

• Our product provides a capability for clients to upload their own NOSTRO list. We would perform enrichment based on the list before sending out the Customer or Bank Transfers provided that the clients have subscribed to the service.

SSI enrichment

• Our product has integrated with SWIFTRef to download the SSI PLUS V3 list. We would perform enrichment based on the list before sending out the Customer or Bank Transfers provided that the clients have subscribed to the service.

• Clients do not need to send a separate Cover message since our product can identify & generate the Cover message.

• Our product would perform validations and enrichment on the Customer or Bank Transfer and the Cover message.

1. Inbound Customer Transfers and Bank Transfers with underlying cover payment

2. Inbound Cover Messages

   1. Cover Payment is a bank-to-bank transfer in favor of a financial institution (beneficiary bank). It comprises sequence A which specifies the actual cover instruction, and sequence B which specifies the ultimate beneficiary information in the payment chain.

   2. Cover Advice is a notification that the financial institution’s account had been credited. The financial institution is the ultimate beneficiary in cover payment.

• Our product would find the best match of Cover Messages with the Customer or Bank Transfers.

• Clients could do manual linking on Cover Messages with Customer or Bank Transfers if needed.

• Clients would need to have access to the “Cover Manager” Role.

• Clients are responsible for monitoring and handling transactions in the ‘Waiting for Cover’ queue.

• Clients are responsible for ensuring that the Cover Payment is processed when the Customer/Bank Transfer is matched using Cover Advice.

• Clients may perform manual linking at any time.

1. Outbound Message Initiation

   1. Request for Cancellation

   2. FI to FI payment Cancellation Request

   3. Customer Payment Cancellation Request

2. Inbound Message reception

   1. Answers

   2. Resolution of Investigation

• Clients could initiate a cancellation request from our product on the Customer or Bank Transfers that have already been sent out.

• Clients could receive the cancellation response from the next agent and perform the necessary actions accordingly.

• The client would need to have access to the “Request for Cancellation” Role.

• The client would need to perform the necessary refund or return manually after a transaction is cancelled.

• The client would need to bear the risk of canceling the transaction.