Skip to main content
Back Custom print Text Only Rich Text Print / Save as PDF
Download Original PDF

  • 4.1. Overview of AFAQ Service's Architecture

    The AFAQ Service is made up of the following components: 
     
     •Sending Domestic RTGS system,
     
     •Sending Regional Payment Gateway (RPG),,
     
     •Central Component,
     
     •Receiving Regional Payment Gateway (RPG),
     
     •Receiving Domestic RTGS system,
     
     •Communications network linking all of the other components of the full system,
     
     •In the case of the countries using the CSM, the functions of the Domestic RTGS system, for both Sending & Receiving cross-border payments, will be performed at the AFAQ Service CC. The service is technically hosted by GPC. The service is managed by the NCB of the country using the CSM as part of their Domestic RTGS services.
     

    • 4.1.1 Sending Domestic RTGS

      The Sending Domestic RTGS system, operated by that country's NCB, handles all communications with the Direct Participants in the sending country. It also deals with all aspects of the processing of outward cross- border payments in accordance with the OR of that country's Domestic RTGS system, including, message validation, accounting, verification of availability of funds on the account of the Sending Participant, debiting the account of the Sending Participant, crediting the account of the Receiving NCB and translation of the messages, if necessary, to the format required by the Sending RPG.

    • 4.1.2 RPG

      RPG’s main functions are to validate, transform and route the cross-border payment messages. 
       
       •Message routing and validation,
       
       •Message queuing in any event causing the AFAQ Service or RPG to queue messages until they can be delivered,
       
       •Handling of Payment Completion Confirmations,
       
       •Exception handling and return of payments,
       
       •Systems management and access control,
       
       •Synchronization of static data with the AFAQ Service cc.
       
       •Holding of the current Participant Directory for message validation purposes.
       
       •Holding of the current FX Translation Rates table for message validation purposes.
       
       •Holding of the current Calendar for message validation purposes.
       
       •Conversion of message formats MX from/to MT.
       
       •Rejection of cross-border cross-currency payments where validation fails.
       

    • 4.1.3 Sending RPG

      The Sending RPG, operated by that country's NCB, receives individual payment messages from the Sending Domestic RTGS system, validates the message format, encrypts all the sensitive data, adds the summary data required for settlement and prepares the full message for transmission to the AFAQ Service CC. The Sending RPG also processes Payment Completion Confirmation messages from the AFAQ Service CC and matches them with the previously sent payment messages.

    • 4.1.4 Receiving RPG

      The Receiving RPG, operated by that country's NCB, receives payment messages from the AFAQ Service CC, decrypts the sensitive data, translates the messages into the format required by the Receiving Domestic RTGS system and forwards the messages to the Receiving Domestic RTGS.

      Any data not included in the message from the Receiving RPG to the Receiving Domestic RTGS system is retained and available in the Receiving RPG. Receiving Direct Participants and Receiving NCBs have access to this data.

      The Receiving RPG also processes Payment Completion Confirmation messages from the Receiving Domestic RTGS, matches them with the previously sent payment messages and transmits the Completion Confirmation to the AFAQ Service CC.

    • 4.1.5 AFAQ Service CC

      The AFAQ Service CC will perform the following main functions: 
       
       •Receive payment messages from the Sending RPG,
       
       •Validate the message format and content,
       
       •Perform the accounting entries over the shadow accounts of sending and receiving NCBs, and the Primary Accounts of Direct Participants in the case of countries using the CSM,
       
       •Transmit the payment message to the Receiving RPG, or, to the Direct Participants in the case of countries using the CSM,
       
       •Process Payment Completion Confirmation messages from the Receiving RPG, match them with the previously sent payment messages and transmit the Completion Confirmation to the Sending RsPG, or, to the Direct Participants in the case of countries using the CSM,
       
       •Process payment rejections and returns,
       
       •Maintain the Direct Participants directory,
       
       •Maintain FX Exchange Rates for cross-currency conversion and end-of-day Settlement,
       
       •Maintain the Business Day Timetable and Calendar,
       
       •Provide enquiry services to NCBs, and to the Direct Participants in the case of countries using the CSM,
       
       •Produce and transmit MT950 Shadow Account statements at end-of-day, and
       
       •Perform end-of day Settlement activities.
       

    • 4.1.6 Receiving Domestic RTGS

      The Receiving Domestic RTGS system, operated by that country's NCB, handles all communications with the Direct Participants in the receiving country. It also deals with all aspects of the processing of Inward cross-border payments in accordance with the rulebook of that country's RTGS system, including, debiting the account of the Sending NCB, crediting of the account of the Receiving Participant, sending of the Payment Completion Confirmation to the Receiving RPG and transmission of the inward payment message to the Receiving Participant.

    • 4.1.7 Country Specific Model (CSM)

      The architecture for the CSM is the same as for the standard RPG configuration except that there is no automated communication with the country's Domestic RTGS system that processes domestic transactions.