# FINASTRA # Fusion Global PAYplus # System Integration - Single Transactions # Business Guide Product Version: 4.6.24 Catalog ID: GPP4.6-00-B54-19-202212 --- Copyright © 2009-2022 Finastra International Limited, or a member of the Finastra group of companies (“Finastra”). All Rights Reserved. Confidential - Limited Distribution to Authorized Persons Only, pursuant to the terms of the license agreement by which you were granted a license from Finastra for the applicable software or services and this documentation. Republication or redistribution, in whole or in part, of the content of this documentation or any other materials made available by Finastra is prohibited without the prior written consent of Finastra. The software and documentation are protected as unpublished work and constitute a trade secret of Finastra International Limited, or a member of the Finastra group of companies, Head Office: Four Kingdom Street, Paddington, London W2 6BD, United Kingdom. # Disclaimer Finastra does not guarantee that any information contained herein is and will remain accurate or that use of the information will ensure correct and faultless operation of the relevant software, services or equipment. This document contains information proprietary to Finastra. Finastra does not undertake mathematical research but only applies mathematical models recognized within the financial industry. Finastra does not guarantee the intrinsic theoretical validity of the calculation models used. Finastra, its agents, and employees shall not be held liable to or through any user for any loss or damage whatsoever resulting from reliance on the information contained herein or related thereto. The information contained in this document and the general guidance of Finastra staff does not take the place of qualified compliance personnel or legal counsel within your institution. # Legal Disclaimer FINASTRA CANNOT RENDER LEGAL, ACCOUNTING OR OTHER PROFESSIONAL SERVICES TO YOUR INSTITUTION. THE INFORMATION CONTAINED HEREIN IS GENERAL IN NATURE AND DOES NOT CONSTITUTE LEGAL ADVICE OR A LEGAL OPINION. CONSULT YOUR LEGAL COUNSEL FOR LEGAL ADVICE SPECIFIC TO YOUR SITUATION OR CIRCUMSTANCES OR TO ANSWER ANY LEGAL QUESTIONS. This document is not intended as a substitute for formal education in the regulatory requirements of banking, banking operations, lending, lending operations, or other topics generally applicable to financial institutions. Your financial institution is solely responsible for configuring and using the software or services in a way that meets policies, practices, and laws applicable to your institution, including, without limitation: (1) options and selections made on prompts; (2) entries in the software program; (3) program setup; and (4) documents produced by the software or services. It is the obligation of the customer to ensure that responsible decisions are taken when using Finastra products. Information in this document is subject to change without notice and does not represent a commitment on the part of Finastra. # Feedback Do you have comments about our guides and online help? Please address any comments and questions to your local Finastra representative. Need more information? Read more about our products at http://www.finastra.com or contact your local Finastra office at http://www.finastra.com/contact. --- # Version Control | Version | Date | Summary of Changes | | ------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1.0 | | Document Created | | 2.0 | Mar 2016 | Added Compliance and Online Foreign Exchange Interfaces | | 3.0 | Jun 2016 | Some formatting and rephrasing updates | | 3.1 | Nov 2016 | Addition of a note regarding the non-persistence of account and customer attributes fetched through Account Lookup | | 3.2 | Feb 2017 | Addition of a more specific instruction as per the content of customer attributes returned from Account Lookup | | 3.3 | Apr 2017 | Update Balance Inquiry section:- A fix of available buttons in Balance Wait queue - A fix in the phrasing for the Balance Reservation request process and required configuration, and in the phrasing of automatic retires of Balance Inquiry - An additional note in the Account Lookup section describing the addition of the IBAN to the Request when it is provided in the transaction. | | 3.4 | May 2017 | Updated with missing action from Posting Exception queue Added the Seize functionality to Compliance Interface, Processing section | | 3.5 | Jul 2017 | Updated with change in the alias of the External Interface checkbox in Accounts profile Move order of paragraphs in Processing section of Account Lookup Added a bullet in Response handling (in all chapters) regarding the Timeout functionality | | 3.6 | Aug 2017 | Updated with a note regarding configuration not to store Feeder message in Processing Communications | | 4.0 | Dec 2017 | Added Advices Interface section | | 5.0 | Jun 2018 | Updated with additional details and fixed to reflect GPP behavior | | 6.0 | Jul 2018 | Added Fraud Interface section Added multiple error log notes | | 7.0 | Oct 2018 | Updated Fraud Interface section for Single Payments Updated Advices Interface section with email notifications | | 8.0 | Dec 2018 | Updated Advices Interface section with fax notifications | | 9.0 | Jun-2019 | Added Essence Support Added Synchronous Interface capability Added pain.001 to Feeder Interface – Capturing and Storing Message Rates | | 10.0 | Nov-2019 | Added Fusion Essence support to Balance Inquiry | | 11.0 | Jan-2020 | Added Fees Interface | | 12.0 | May-2020 | Updates: Overview: Fndt Message note Added: Balance Inquiry - Error Codes section | | 13.0 | Jul-2020 | Online Foreign Exchange Interface • Overview: Added External Interface with FX Provider bullet | Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 3 --- # Fusion Global PAYplus | System Integration - Single Transactions | Business Guide | Version | Date | Summary of Changes | | ------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 14.0 | Aug-2020 | Added Fraud Service Provider Interface (SPI) for Single Payments | | 14.0 | Dec 2020 | Updated 3.3.1.1 Wait CDB Response (CDBWAIT) Queue section for Send to Repair action. | | 15.0 | Mar 2021 | Added Send to Repair action for CDBSTOP queue in 3.3.2.1 Inactive CDB (CDBSTOP) Queue. | | 16.0 | June 2021 | Added new section for Billing Events Interface | | 17.0 | July 2021 | * Added section for Payment Source * OFAC Possible Hit Queue (OFAC\_POSSIBLE\_HIT): Added Reject/Return | | 18 | Oct 2021 | Added Rate Direction to the Capturing and Storing Message Rates section and under the Usage of Rates Related Information section. | | 19 | Nov 2021 | Removed outward transaction only comment for Cancel action | | 20 | May 2022 | Added Retry action button in manual handling – Wait queues | | 21 | August 2022 | - Added group action details in relevant queues - Added system parameters in BI System Parameter section - Updated section: Handling Earmark Release Request | | 22 | December 2022 | Added Cancellation invocation point | Page 4 --- Table of Contents # 1 INTRODUCTION .......................................................................................................................... 8 # 1.1 Overview ............................................................................................................................... 8 # 1.2 Target Audience .................................................................................................................... 8 # 2 HIGH LEVEL INTEGRATION FLOW .......................................................................................... 8 # 3 ACCOUNT LOOKUP INTERFACE ............................................................................................. 9 # 3.1 Overview ............................................................................................................................... 9 # 3.2 Processing .......................................................................................................................... 11 # 3.2.1 Workflow .......................................................................................................................... 11 # 3.2.2 Details .......................................................................................................................... 12 # 3.2.3 Response/Request Matching .......................................................................................... 15 # 3.3 Manual Handling ................................................................................................................. 15 # 3.3.1 Wait Queues .................................................................................................................... 15 # 3.3.2 Inactive Queues ............................................................................................................... 15 # 3.3.3 Manual Handling Queues ................................................................................................................. 16 # 3.3.4 Resume from Manual or Wait Statuses .......................................................................... 17 # 3.4 Business Setup and System Configuration ............................................................................... 17 # 3.4.1 Business Setup ................................................................................................................ 17 # 3.4.2 System Configuration ...................................................................................................... 19 # 3.5 Message Data ..................................................................................................................... 19 # 4 ADVICES INTERFACE .............................................................................................................. 19 # 4.1 Overview ............................................................................................................................. 19 # 4.2 Advices Interface Message Types ...................................................................................... 20 # 4.3 Non-Interface Message Types ............................................................................................ 20 # 4.4 Processing .......................................................................................................................... 20 # 4.4.1 Details .............................................................................................................................. 20 # 4.5 Manual Handling ................................................................................................................. 23 # 4.6 Business Setup and System Configuration ............................................................................... 23 # 4.6.1 Business Setup ................................................................................................................ 23 # 4.6.2 System Configuration ...................................................................................................... 24 # 4.7 Message Data ..................................................................................................................... 25 # 4.7.1 Audit Trail Entries ............................................................................................................ 25 # 4.7.2 Error Codes ..................................................................................................................... 25 # 5 BALANCE INQUIRY INTERFACE ............................................................................................ 25 # 5.1 Overview ............................................................................................................................. 25 # 5.2 Processing .......................................................................................................................... 26 # 5.2.1 Balance Check ................................................................................................................ 26 # 5.2.2 Earmark Release ............................................................................................................. 30 # 5.2.3 Automatic Retries ............................................................................................................ 32 # 5.2.4 Response/Request Matching .......................................................................................... 33 # 5.2.5 Fusion Essence System Support .................................................................................... 33 # 5.3 Manual Handling ................................................................................................................. 33 # 5.3.1 Wait Queues .................................................................................................................... 33 # 5.3.2 Inactive Queues ............................................................................................................... 34 # 5.3.3 Manual Handling Queues ................................................................................................................. 35 Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 5 --- # 5.4 Business Setup and System Configuration # 5.4.1 Business Setup # 5.4.2 System Configuration # 5.5 Message Data # 5.5.1 Error Codes # 6 COMPLIANCE INTERFACE # 6.1 Overview # 6.2 Processing # 6.2.1 Predebit and Preposting Invocation Point # 6.2.2 Cancellation Invocation Point # 6.2.3 Response/Request Matching # 6.3 Manual Handling # 6.3.1 Wait Queues # 6.3.2 Inactive Queue # 6.3.3 Manual Handling Queues # 6.4 Business Setup and System Configuration # 6.4.1 Business Setup # 6.4.2 System Configuration # 6.5 Message Data # 7 FEEDER INTERFACE # 7.1 Overview # 7.2 Processing # 7.2.1 Workflow # 7.2.2 Handling the Feeder Request # 7.2.3 Usage of Information Received During Processing # 7.2.4 Response/Acknowledgment Initiation # 7.3 Manual Handling # 7.3.1 Wait Queues # 7.3.2 Manual Handling Queues # 7.4 Business Setup and System Configuration # 7.4.1 Business Setup # 7.4.2 System Configuration # 7.5 Message Data # 8 FEES INTERFACE # 8.1 Overview # 8.2 Interface Modes # 8.3 Supported Transaction Types # 8.4 Processing # 8.4.1 Details # 8.4.2 Response/Request Matching # 8.5 Manual Handling # 8.5.1 Manual Handling Queues # 8.5.2 Wait Queues # 8.5.3 Inactive Queue # 8.6 Business Setup and System Configuration # 8.6.1 Business Setup # 8.6.2 System Configuration --- # Fusion Global PAYplus | System Integration - Single Transactions | Business Guide # 8.7 Message Data ..................................................................................................................... 65 # 9 FRAUD INTERFACE ................................................................................................................. 65 # 9.1 Overview ............................................................................................................................. 65 # 9.2 Fraud Interface for Single Payments Using Financial Institution’s Fraud System ...................................................................................................................... 66 # 9.2.1 Processing ....................................................................................................................... 66 # 9.2.2 Response/Request Matching .......................................................................................................................... 69 # 9.2.3 Manual Handling .............................................................................................................. 69 # 9.2.4 Business Setup and System Configuration ..................................................................................................... 70 # 9.2.5 Message Data ................................................................................................................. 71 # 9.3 Fraud Service Provider Interface (SPI) for Single Payments ............................................................................................................. 71 # 9.3.1 Processing ....................................................................................................................... 71 # 9.3.2 Manual Handling .............................................................................................................. 73 # 9.3.3 Business Setup and System Configuration ..................................................................................................... 75 # 9.4 Fraud Interface for Immediate Payment ............................................................................................................. 76 # 9.4.1 Processing ....................................................................................................................... 76 # 9.4.2 Response/Request Matching .......................................................................................................................... 79 # 9.4.3 Manual Handling .............................................................................................................. 79 # 9.4.4 Business Setup and System Configuration ..................................................................................................... 80 # 9.4.5 Message Data ................................................................................................................. 81 # 10 ONLINE FOREIGN EXCHANGE INTERFACE ......................................................................................................... 81 # 10.1 Overview ............................................................................................................................. 81 # 10.2 Processing .......................................................................................................................... 82 # 10.2.1 Workflow .......................................................................................................................... 82 # 10.2.2 Details .............................................................................................................................. 83 # 10.3 Manual Handling ................................................................................................................. 83 # 10.3.1 Manual FX Updates ......................................................................................................... 83 # 10.3.2 Wait Queues .................................................................................................................... 84 # 10.3.3 Manual Queues ............................................................................................................... 85 # 10.4 Business Setup and System Configuration ........................................................................................................ 88 # 10.4.1 Business Setup ................................................................................................................ 88 # 10.4.2 System Configuration ...................................................................................................... 89 # 10.5 Message Data ..................................................................................................................... 89 # 11 POSTING INTERFACE ............................................................................................................. 89 # 12 BILLING EVENTS INTERFACE ................................................................................................................ 89 # 12.1 Overview ............................................................................................................................. 89 # 12.2 High Level Workflow ........................................................................................................... 90 # 12.3 Business Setup ................................................................................................................... 90 # 12.3.1 System Parameters ......................................................................................................... 90 # 12.3.2 Billing Event Interfacing Profile ................................................................................................. 90 # 12.3.3 Interfaces ......................................................................................................................... 90 # APPENDIX A: MANUAL ACTIONS PER QUEUES ............................................................................................................ 91 # APPENDIX B: GLOSSARY ................................................................................................................ 100 Page 7 --- # 1 Introduction # 1.1 Overview Fusion Global PAYplus (GPP) can integrate with a financial institution’s systems via various interfaces. Each interface is dedicated to a specific functionality. GPP provides a standard message structure, which is referred to as the Fndt Message (FuNDs Transfer Message). The structure is used for the interfaces which are decoupled from the functionality around the interfaces’ invocation and usage of the information they provide as part of the GPP processing. Note: The external Fndt Message structure that GPP transmits to various external interfaces, such as, the Account Lookup interface, is static and not given to updates for internal format changes. GPP updates the structure only when these interfaces are required to expose additional attributes. This Business Guide describes the business functionality as part of single payment processing and manual handling that is supported in relation to the supported interfaces. The request and response details are available in the relevant Interface Technical Guide. Note: This document describes the business processing, manual handling and configuration required for GPP standard interfaces except for the Posing interface. For a description of the Posting interface, see GPP Business Guide Posting. # 1.2 Target Audience This business guide is intended for business analysts and product managers who need to understand the integration capabilities including the configuration and utilization per each interface type supported by GPP. # 2 High Level Integration Flow GPP supports invocation of various interfaces during its single payment processing flows, each for a specific functionality. This business guide describes the business functionality for each of the supported interfaces. --- # Legend - Standard Interfaces - Channels - Best Practice Integration Layer - Global PAYplus Future - Internal Integration / Transformation Layer # Services | Order | Feeder | Management | Integration | | | | | ----------- | ------------------- | -------------- | ------------- | ----------------- | --------------------- | ----- | | Integration | File Validation and | Single Payment | Ack and | CIF | Customer DB | | | Queue List | Processing | Enrichment | Initiation | Notification | Lookup | | | Layer | | Customer DB | Investigation | Payment Execution | Balance Investigation | Check | # Liquidity & Risk Profile | Mass Payments | Immediate High Value Payments | Account Core Banking | | ----------------- | ----------------------------- | -------------------- | | Upload Management | Posting | Core Banking | # Reference Data | Core Services | FX Reference Data | | ------------------- | ----------------------------- | | SWIFTref | Sanctions | | Real Time upload | Infrastructure and Data Layer | | Real Time FX Engine | FX Engine | # Last Mile Solutions | Customer Advising | SWIFT | | | | | ----------------- | ----------------- | -------- | ----------------- | ----------------- | | SAA | RMA | SWIFT T2 | Euro1 | | | | | | Fees and | Sanctions / Fraud | | SAA upload | Billing | | Sanctions / Fraud | | | FATF | FATF Notification | | | | # Integration Layer Billing Engine # Account Lookup Interface # 3.1 Overview GPP invokes the Account Lookup interface to retrieve account and customer information required for the generic GPP transaction processing workflow. GPP invokes the interface for each transaction after the Debit Derivation and Credit Derivation subprocesses of the transaction processing workflow. GPP uses the interface to retrieve and load debit and credit account details. GPP can invoke either of the following types of Account Lookup Interfaces: - External: GPP invokes the external Account Lookup interface via the GPP Gateway, which is a proprietary GPP component designed and developed to provide a scalable platform to handle a variety of messaging formats when communicating with external interfaces and microservices. For more information about the Gateway, see the GPP Gateway Technical Guide and the GPP Interfaces over Gateway - Single Transactions Business Guide. - Internal: GPP invokes the internal Account Lookup interface for accounts managed within GPP. In this type, as described here, Account Lookup interface responses and requests use the standard FuNDs Transfer (Fndt) Message format. --- # GPP Account Lookup Business Rules GPP evaluates the Account Lookup business rules when either the credit account or the debit account is not an account maintained in the GPP Accounts profiles repository, or if the account does exist but it is marked to invoke the Account Lookup interface (External lookup checkbox is selected). Based on the rules evaluation results, if the selected rule contains the action External, GPP invokes the Account Lookup interface. GPP does not perform Account Lookup for Fee accounts. Once the Account Lookup interface is invoked, and if the interface is working in A-sync mode, the message processing is stopped and the message waits for the response in the queue (status) of Wait CDB response (CDBWAIT). Account information captured from the Account Lookup response may include the following: - Holding customer identification, Name, and Address details (Country, State, City, Zip, Street Address) - Customer and account categorization that may affect processing (such as FX and Fees) - Booking entity the account is assigned to (accounting system in which the account is managed) - Account type, the values are as defined in GPP Account Types profiles - Posting restriction that may exist on the account When a failure in the request processing occurs on the HOST, response details are expected to specify the errors encountered in the request processing. These errors may be related to a technical issue, or functional issue. The message processing is resumed in GPP after the receipt of the Account Lookup response based on the response received: - If positive response with no posting restrictions, GPP stores the account information and the message continues the processing to the next step. - If a response with posting restrictions, the message is routed to the Posting Restriction (POSTREST) queue, for manual override or retry. - If technical error response (return code 990) is received, the payment is routed to the Inactive queue depending on the interface inactivity behavior set up. - If general negative response, either technical or functional return code 0 is received, the message is routed to the Repair (REPAIR) queue, for manual handling. - If negative response, either technical or functional, the message is routed to the Repair (REPAIR) queue, for manual handling. GPP supports a GPP Standard Account Lookup format that is suggested to be used for this interface. For more details on this format, see GPP Technical Guide - Fndt Message Usage for Account Lookup Interface document. GPP can also support a proprietary format as per the financial institution’s preference, once initial mapping effort is included between the proprietary format and the GPP attributes, and as long as the necessary information exists in this proprietary format. Note: the account and customer attributes (F_ fields) retrieved using the Account Lookup are available to be used in processing rules during the processing of the transaction. However, once the transaction reaches the final status this information is not kept in the context of the transaction. It can be viewed as part of the structure of the Account Lookup Response within the full XML structure via the Processing Communication page, but cannot be used for searching or filtering the repository of transactions. --- # 3.2 Processing # 3.2.1 Workflow Start Dr/Cr side Processing | Load account and party from GPP DB | Success | Yes | | ---------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------- | | External lookup set? | No | Yes | | | No | Evaluate Account Lookup Selection rules | | Create account | ~~Yes~~ | Account lookup request | | | Lookup Rule found? | No | | Continue HV payment flow | Wait Behavior | WaitCDB | | Response received | ~~No~~ | User Action | | MEI screen | Copy and resend original request with a new delivery timestamp (same EventID) | | | Yes | Send to Repair | | | Successful response? | Yes | (MI\_CDB\_STS=P) | | No | Change account | (MI\_CDB\_STS=N) and Submit | | Posting restrictions | No, Failure response | User Action | | Yes | Send to Repair | Cancel | | Posting Restrictions | User Action | Canceled | | POSTREST | Retry Post.Rest – to resend with retry monitor | Override Post. Rest (if stop flags is overridable) | | | (new EventID) | | Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 11 --- # 3.2.2 Details # 3.2.2.1 Handling Account Lookup Request These are the different scenarios for Account Lookup invocation: - Outgoing (feeder/manual create) Credit Transfer transactions: GPP performs Account Lookup in the following cases: - On the debit account: Debtor account identification is provided in the message but additional required information is not provided, and the debtor account does not exist in GPP, or exists in GPP but is marked to be rechecked in Host (External lookup checkbox is selected). It is assumed that the debtor is a financial institution’s customer. - On the credit account: Credit account identification is provided in the message without the additional required information, and creditor is a financial institution’s customer (creditor agent is the local office), and credit account does not exist in GPP, or exists in GPP but is marked to be rechecked in Host (External lookup checkbox selected). Note: GPP can generate and transmit an Account Lookup request for this transaction type to Finastra’s Fusion Essence system. For more information, see Fusion Essence Account Lookup. - Outgoing (feeder/manual create) Debit Transfer (collection) transactions: GPP performs Account Lookup in the following cases: - On the debit account: Debtor account identification is provided in the message but additional required information is not provided, the debtor is a financial institution customer (debtor agent is the local office), and the debtor account does not exist in GPP, or exists in GPP but is marked to be rechecked in Host (External lookup checkbox selected). - On the credit account: Credit account identification is provided in the message without the additional required information, and credit account does not exist in GPP, or exists in GPP but is marked to be rechecked in Host (External lookup checkbox selected). - Incoming Credit Transfer transactions: GPP performs Account Lookup in the following case: - On the credit account: Credit account identification is provided in the message without the additional required information, and credit account does not exist in GPP, or exists in GPP but is marked to be rechecked in Host (External lookup checkbox selected). It is assumed that the creditor is a financial institution’s customer (otherwise the transaction is an onward transaction). Note: GPP can generate and transmit an Account Lookup request for this transaction type to Finastra’s Fusion Essence system. - Incoming Debit (Collection) transactions: GPP performs Account Lookup in the following case: - On the debit account: Debtor account identification is provided in the message without the additional required, and the debtor account does not exist in GPP, or exists in GPP but is marked to be rechecked in Host (External lookup checkbox selected). It is assumed that the debtor is a financial institution’s customer. - Onward transactions: GPP is not expected to perform Account Lookup as none of the accounts (debit/credit) are a customer account. Note: GPP can generate and transmit an Account Lookup request for this transaction type to Finastra’s Fusion Essence system. Note: When an IBAN is provided as the account in the transaction, this IBAN, in addition to the deconstructed Account Number, is also sent within the Account Lookup request, to allow identification by it in the financial institution’s system. GPP can include in the request a unique 16-character Event ID each time the transaction triggers the Account Lookup interface (if using the GPP Standard Account Lookup format this ID is quoted in the EventId tag within the Header section): - When it is an override request, the request is sent quoting a new Event ID. --- • When it is a re-invocation after manual or wait queue, the request is sent quoting a new Event ID. • When it is resend, the request is sent quoting the original Event ID. The Event ID is stored in the Message external interaction (EVENT_ID column), for interfaces that are configured to create a MESSAGE_EXTERNAL_INTERACTION entry, and the EVENT_ID_GENERATION field is set to 1 in their INTERFACE_TYPES entry. It is generated with the algorithm being similar to MID generation, including letters, numbers, and date & time, and it is saved, and can be used, in the D_MEI_EVENT_ID Logical Field. GPP stores the request in the Processing Communications (MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct so. For all of the scenarios of Account Lookup Invocation, whenever the message is released from a manual or wait queue (for example Posting Exception, Schedule), another validation request via Account lookup is sent to the HOST system, to make sure that the account is still valid. # 3.2.2.2 Fusion Essence Account Lookup GPP can generate and transmit an Account Lookup request to Fusion Essence to receive account information when processing specific types of transactions (see Handling Account Lookup Request). GPP accesses the IS_ESSENCE_CDB system parameter (see System Parameters) when invoking the Account Lookup interface. If the parameter is set YES, GPP generates an Account Lookup request and transmits it to Fusion Essence in a synchronous mode. Upon receipt of a response from Fusion Essence, GPP continues with the generic Account Lookup workflow. Finastra’s Fusion Essence solution is a core banking platform that enables banks to manage their total customer experience. For more information, see the relevant Finastra Fusion Essence documentation. # 3.2.2.3 Handling Account Lookup Response - GPP parses the response. - GPP validates that the response is structurally valid, against the relevant defined structure, either the Standard Fndt Message or a financial institution specific proprietary structure per this interface type. - GPP performs matching between the response and the relevant request. For more details on the matching functionality see Response/Request Matching. - GPP stores the response in the Processing Communications (MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct so. - Audit trail of the transaction is updated to indicate that a response was received. For a negative response, a response error description is also added to the message error log. - Note: If the response contains multiple errors, GPP generates an error log entry for each error. - GPP evaluates the response value to decide to where it should route the transaction. For more information, see Successful Response and Failure Response. - If a previous response was already received for the matched request (automatic or manual retry were performed and the original response was received after the retried request was sent) and the message already continued the processing, the latest response is ignored (saved in Processing Communications (MESSAGE_EXTERNAL_INTERACTION) for the record, if configured so, but does not affect the processing). - If the response is not received within a configurable timeout period, timeout will be retried per configured number of retries on the Interface Type, after which - Interface becomes inactive and --- # 3.2.2.3.1 Successful Response - GPP validates that the response contains the required information. - GPP expects the response to contain Creditor (full or reference to a Party configured in GPP using the External ID attribute) and Credit Account information if the request provided the Creditor account Identification and was sent with of CreditAccountLookup. - GPP expects the response to contain Debtor (full or reference to a Party configured in GPP using the External ID attribute) and Debit Account information if the request provided the debit account identification and was sent with of DebitAccountLookup. - GPP captures the information provided in the Account Lookup response. - GPP stores the information in the transaction data. - When the fee information is provided in the Account Lookup response, GPP captures and stores the message fees information. For more information, see Capturing and Storing Message Fees. - When the contact information is provided in the Account Lookup response, GPP stores a Contact details occurrence per each contact, reflecting its association to either the debit or credit account or party. # 3.2.2.3.1.1 Capturing and Storing Message Fees Same functionality and handling as if received from Feeder. For more information, see Capturing and Storing Message Fees. # 3.2.2.3.2 Failure Response - GPP captures the error reasons provided in the response details. - If required, GPP maps the provided errors to GPP errors, based on a predefined error mapping conversion. - GPP adds these errors to the message errors. Note: If the response contains multiple errors, GPP generates an error log entry for each error. - GPP routes the transaction to the relevant queue (Posting Restrictions (POSTREST) or Repair (REPAIR)) based on the response received. For more information, see details in Manual Handling. # 3.2.2.4 Usage of Information Received During Processing Later in the process, GPP uses the information received in the Account Lookup response for: - Account validation - Debtor/Creditor information enrichment, for example, with name and address information required in the transaction submitted to clearing scheme. - Fee calculation – For more information, see Usage of Fees Information. - Balance inquiry - Posting restriction check, if restrictions were reported. - Posting entries generation (including entries for the fees reported in this response) and posting interface - Advising (using the contact information provided in the response) # 3.2.2.4.1 Usage of Fees Information Same functionality and handling as if received from Feeder. For more information, see Usage of Fees Information. --- # 3.2.3 Response/Request Matching In general, on Request/Response interfaces GPP supports a functional and technical matching functionalities between the request, sent from GPP, and the response, received from the external financial institution system. The functional, and more generic, method is the usage of <ContecName> and <contexLocalName>, quoting, in the response, their value/s from the request + the P_MID. Specifically for Account Lookup the usage of <contexName> in matching ensures matching of debit side Account Lookup response to the debit side Account Lookup request, and the same for credit side. There are additional technical methods that allow echo back of the sending system (GPP in these cases) identifier in a custom property of the MQ header (the value of this identifier was captured from the request as transport property) or using the MQ correlation ID in the MQ envelope. Note: The Event ID currently is not used in the matching, therefore, it is not mandatory to be returned in the response. # 3.3 Manual Handling This section describes the various scenarios in which a single transaction may be stopped in relation with the Account Lookup interface: - In a wait queue until the relevant response is received, or - In an inactive queue until the interface is active again, or - A manual queue due to information received from the response The description is per such specific manual queues. For a summary of actions per queue, see Appendix A: Manual Actions per Queues. # 3.3.1 Wait Queues # 3.3.1.1 Wait CDB Response (CDBWAIT) Queue A single transaction is stopped in this queue after an a-sync Account Lookup request is sent to the external system, and until an Account Lookup response is received. When using synchronous mode, the process is not stopped but waits for an online response, and the transaction is not parked in any queue. In this queue the user can perform one of the following actions: - Cancel: The transaction is routed to cancellation flow, including earmark release, when required (for example, if the Account Lookup is pending on the target credit account, while Balance Inquiry on the debit account already took place), or reverse posting, when required (for example, if the Account Lookup is on the target credit account, while Posting on the debit leg already took place). - Send to Repair: GPP routes the transaction to Repair status. - Retry: Instructs GPP to re-submit a single or multiple transactions (at once) for processing. A request is generated for each payment, and the payment waits for the response in the same (Wait CDB Response) queue. # 3.3.2 Inactive Queues When the relevant interface is not active or a technical negative response is received (return code 990), GPP behaves according to the inactive behaviour set for this interface, as per the generic interfaces functionality (for more details see GPP Interfaces Technical Guide). For the interfaces that are configured with Non-active behavior of STOP_UNTIL_ACTIVE or PERMANAET_STOP, the inactive queues are where the transaction waits for the relevant interface to become active. --- # 3.3.2.1 Inactive CDB (CDBSTOP) Queue If the Account Lookup interface Non-active behavior is setup as STOP_UNTIL_ACTIVE or PERMANENT_STOP, when the interface goes down, the transaction is visible to the user in the Inactive CDB (CDBSTOP) queue. In this queue, users can perform Cancel and Send to Repair actions. # GPP Processing: - Cancel: The transaction is routed to cancellation flow, including earmark release, when required (for example, if the Account Lookup cannot be performed on the target credit account, while Balance Inquiry on the debit account already took place), or reverse posting, when required (for example, if the Account Lookup cannot be performed on the target credit account, while Posting on the debit leg already took place). - Send to Repair: Sends the payment to Repair status. # 3.3.3 Manual Handling Queues # 3.3.3.1 Posting Restrictions (POSTREST) Queue A single transaction may be stopped in this queue following a negative Account Lookup response, with posting restrictions/limitations on the account or the customer (meaning that a valid Stop Flag existing in GPP is quoted as the reason for the failure). Authorized users can perform the following actions: - Override: Instructs to override the restriction for a single transaction or multiple transactions (only active for a transaction that was stopped due to an overridable Stop Flag), and route the transaction(s) to continued processing, as follows: - The relevant CDB monitor is set to P to allow skipping an additional invocation of the Account lookup, when message is reprocessed. - In addition, the MU_STOP_FLAGS_OVERRIDE_STS is set to O, to indicate that the posting restriction was overridden, and processing continues from this point in the flow. - Later in the flow, once reaching the points of Balance Check and Posting, these requests are triggered and include the additional information of the user decision to override posting restriction, either specifically quoting the MU_STOP_FLAGS_OVERRIDE_STS monitor as O, or in the case of Posting request, providing a more general force indication for all posting entries, which is relevant for both user actions of posting restriction override and force NSF (if using the Standard Fndt Message is F_POSTING_INFO_FORCE_POST_IND=1). - Sets the transaction status to the Approve Override queue and routes it to the Approve Override queue for additional manual handling. The override action must be approved or cancelled by another authorized GPP user or the same user who initiated the action, as per workflow definitions. The user can cancel a single or multiple transactions. - Retry Post. Rest.: Instructs GPP to retry the processing of a single or multiple transactions (at once) by submitting it back to try full reprocessing, and invoking another attempt of the Account lookup (for the relevant side which failed previously due to posting restrictions). The transaction is routed to Wait CDB Response (CDBWAIT) pending response from HOST system. - Send to Repair: Instructs GPP to send the transaction to the Repair (REPAIR) queue for manual user intervention. - Cancel: Instructs GPP to cancel a single transaction or bulk of transactions by routing them to the cancellation flow, including earmark release, when required (for example, if the Account Lookup is on the target credit account, while Balance Inquiry on the debit account already took place), or reverse posting, when required (for example, if the Account Lookup is on the target credit account, while Posting on the debit leg already took place). --- # 3.3.3.2 Repair Queue A single transaction may be stopped in this queue, in relation with interfaces, following an Account Lookup failure response with failure status that is not the specific Posting Restrictions, or due to technical failure. Authorized users can perform the following actions: - Update Transaction Information: After updates, the user can submit the transaction and GPP does the following: - When reaching the point/s of Account Lookup, if the relevant CDB monitor is not set to P to indicate a successful Account Lookup or if relevant account was updated by the user, an additional invocation of the Account lookup for the relevant account is triggered. - When reaching the point of Balance Check: - If the BI monitor is not set to P (i.e. either was stopped before or due to a Balance Inquiry response), the Balance Inquiry interface is triggered. - If the BI monitor is P to indicate a successful Balance Inquiry, but the Posting monitor indicates failure, and if relevant transaction attributes were changed (account, amount, value date), and if working in Earmark mode, an Earmark Release request along with the new Balance Inquiry with earmark hold request are triggered, each quoting a new Event ID. - When reaching the point of Posting the Posting interface is triggered the Posting entries are re-calculated and compared with previous entries not already marked as successful/reversed. If they are different (may happen when relevant transaction attributes (account, amount, value date) were changed), reversed posting entries are created for these non-final entries, along with the newly calculated entries. These are included in the Posting request/s and are sent, quoting a new Event ID. - Cancel: Instructs GPP to cancel the transaction by routing it to the cancellation flow, including earmark release, when required (for example, if the Account Lookup is on the target credit account, while Balance Inquiry on the debit account already took place), or reverse posting, when required (for example, if the Account Lookup is on the target credit account, while Posting on the debit leg already took place). Note: For the Account Lookup interface, the credit Account Lookup is performed on the account of the party that is first in the credit chain (after the GPP chain enrichment). If the credit account was entered manually, while in the Repair queue, and needs to be validated via Account Lookup, it must quote the same first in chain account, as GPP does not take it into account for the credit Account Lookup. # 3.3.4 Resume from Manual or Wait Statuses When a transaction is submitted to resume processing after being stopped in a manual or wait status after the receipt of an Account Lookup interface response, and if the customer and account information were included in the Account Lookup response, these details are reloaded from the Account Lookup response if configured for storage in the MEI database table, which users can view via the GPP User Interface Processing Communication page. This allows their usage in the payment processing. # 3.4 Business Setup and System Configuration # 3.4.1 Business Setup # 3.4.1.1 System Parameters The following table describes the business System Parameters that GPP uses for Account Lookup functionality. --- # 3.4.1.2 Profiles These are the details of the required setup in GPP profiles for the Account Lookup Interface. Note: For a detailed description of all the fields in the profiles, see GPP Online Help. # 3.4.1.2.1 Accounts Profile If the financial institution requires keeping an entry representing an account in GPP, but still regards the Master account entry as the entry managed in the external system, the External lookup check box should be selected in the GPP Accounts entry. GPP then invokes the Account Lookup interface for this account even though an entry exists for it in GPP. # 3.4.1.2.2 Stop Flags Profile The Stop Flag profile is relevant whenever the Account Lookup response may provide Stop Flags or limitations on the account or customer. Stop Flag entries should be defined in GPP for each Stop Flag value that may be provided as a restriction in the Account Lookup response. Each of these Stop Flags may be set as overridable or as non-overridable. In the Posting Restrictions queue the Override option is available for the user only if the Stop Flag reported in the Account Lookup response is an overridable one. No such option is available if the message was stopped due to a non-overridable Stop Flag. # 3.4.1.3 Rules # 3.4.1.3.1 Account Lookup Rules GPP invokes Account Lookup rules to determine whether to invoke the internal or external Account Lookup interface, as follows: - If an account is managed in GPP, GPP can retrieve account information internally from the GPP database. - If an account is not managed in GPP and GPP must execute an external interface call to retrieve account information from a financial institution’s database, the financial institution can define an Account Lookup rule to invoke the Account Lookup over Gateway interface by setting the rule’s Action field to External. Note: A financial institution can define an external Account Lookup for an account managed in GPP using the Account profile of the specific account. For more information, see the GPP Online Help. --- # 3.4.1.4 Permissions Permissions need to be granted to users that need to configure the different business profiles and rules related to the Account Lookup interface. # 3.4.2 System Configuration # 3.4.2.1 System Parameters There are no specific System Parameters, which are business parameters, required for the Account Lookup Interface. # 3.4.2.2 Profiles These are the details of the required setup in GPP system profiles for the Account Lookup Interface. Note: For a detailed description of all the fields in the profiles, see GPP Online Help. # 3.4.2.2.1 Interfaces Relevant Interfaces entries should be configured for the Account Lookup interface (usually it is required to set separate entries for the debit side and for the credit side). The timeout between retries and the maximum number of retries should also be set in these entries according to the financial institution’s requirements. GPP should not continue processing the transaction until the account details are captured. It is therefore recommended, that the Account Lookup interface Non-active behavior is setup as STOP_UNTIL_ACTIVE with the Inactive queue as Inactive CDB (CDBSTOP). For a description of the relevant fields, see the GPP Online Help or the GPP Interfaces Technical Guide. Note: When the Fndt Message format is defined as the structure to use for a specific interface type, GPP can also be setup to control which sections of the generic Fndt Message structure are to be sent out for this Request/Response, from a maximum with a full structure (including all the message related attributes), to a minimum specific per interface type. For example for Account Lookup interface only the sections quoting details of the account, customer and contacts. # 3.4.2.3 Rules # 3.4.2.3.1 Interface Selection Interface Selection rules, selecting the relevant Interface Types entries, should be configured for the Account Lookup interface request. # 3.5 Message Data There are no specific Message Attributes, errors and audit trails for this interface. # 4 Advices Interface # 4.1 Overview The GPP Advices Interface enables a financial institution to generate and transmit advice messages during the transaction processing workflow. GPP uses various types of advice messages to notify financial institution customers of transaction-related events that can occur during transaction processing. For example, GPP can generate and transmit a SWIFT MT900 message to notify a financial institution customer that a debit transaction has been executed on their account. GPP generates the following types of advice messages: --- • Advices Interface: GPP invokes the Advices interface during transaction processing and the interface generates the appropriate message type, each of which contains selected transaction attributes. For more information, see Advices Interface Message Types. • Non-Interface: GPP generates specific SWIFT advice messages during the course of generic transaction processing. For more information, see Non-Interface Message Types. # 4.2 Advices Interface Message Types GPP invokes the Advices Interface during transaction processing and the interface generates the following advice message types: - Acknowledgement: A SEPA acknowledgement message that notifies an initiating party about the positive or negative status of a payment instruction. The advice message can contain a list of selected transaction attributes and other information, as required. GPP can generate one of the following SEPA acknowledgement messages: - pacs.002: A PaymentStatusReport message that one agent sends to another. It is used to provide status information about previously transmitted instructions. - pain.002: A PaymentStatusReport message an instructed agent sends to the previous party in the payment chain. It is used to inform the party about the status of a credit transfer or direct debit transaction. - Event Notification: A message (structured in a proprietary XML format) that contains a list of selected transaction attributes and other information that is required by an external financial institution system, which can use the information to complete an action. GPP transmits the message, after which it is the responsibility of the financial institution to generate the actual advice message. # 4.3 Non-Interface Message Types GPP generates the following SWIFT advice messages during the course of generic transaction processing: - MT900: A Confirmation of Debit message that notifies an account owner of a debit to their account. - MT910: A Confirmation of Credit message that notifies an account owner of a credit to their account. - Email/Fax notification: A notification for customers that a payment is processing (incoming or outgoing), as per the customer requirements. - CAMT_057: A Notice to receive that notifies the beneficiary of a future transfer of funds via correspondent. # 4.4 Processing GPP transaction processing includes both generic workflows and workflows dedicated to specific functionality and transaction types. # 4.4.1 Details During the transaction processing Flow Management sub-flow, GPP invokes Advising Type Selection business rules (see Advising Type Selection Rules) to determine whether to generate and transmit an advice message for a transaction. If GPP determines that a transaction meets the criteria of a defined rule, GPP uses the value in the Advising Profile field of the relevant Advising Type Selection rule to access the ADVCTYPE database table. GPP uses the values in the following table columns to determine the required type of advice message: Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 20 --- • ADVC_VEHICLE: Determines whether GPP generates an interface or non-interface message for the transaction. The column can contain one of the following values: - M: GPP generates non-interface message, as described in Non-Interface Message Types. - Null: GPP generates an interface message, as described in Advices Interface Message Types. • SYSTEM_NOTIFICATION: Determines whether GPP accesses the relevant Advices profile to populate fields, such as contact information, in the outgoing advice message. GPP determines the corresponding profile using the identifier derived from the Payment Data Object (PDO). The column can contain one of the following values: - 0: GPP does not access the Advices profile. - 1: GPP accesses the Advices profile. • EMAILADV: Determines whether to send an email advice to customers. Once the rule is caught, GPP searches all the relevant Advices profiles in the database for the selected advice type and tries to match the customers from the payment to the customers in the profiles (and accounts, if populated). Each profile caught invokes an advice through the selected interface, and multiple advices can be sent for the same payment. • FAXADV: Determines whether to send a fax advice to customers. Once the rule is caught, GPP searches all the relevant Advices profiles in the database for the selected advice type and tries to match the customers from the payment to the customers in the profiles (and accounts, if populated). Each profile caught invokes an advice through the selected interface, and multiple advices can be sent for the same payment. For more information about the Advices profile, see Advices Profile. # 4.4.1.1 Advices Interface Message Generation GPP generates Advices Interface messages (see Advices Interface Message Types) as determined by the value in the Advising Profile field of the relevant Advising Type Selection rule. The field can contain one of the following: - Acknowledgement: GPP generates an Acknowledgement (ACK) message, such as a pain.002 or pacs.002, in the required format with all relevant message attributes and information. - Event Notification: GPP generates an Event Notification message in the defined XML format with all relevant message attributes and information. For more information about rules and profiles, see Business Setup and System Configuration. # 4.4.1.2 Non-Interface Message Generation GPP generates non-interface message types, such as MT900 and MT910, as determined by the ADVC_VEHICLE value in the ADVCTYPE database table (see System Parameters). GPP invokes the Generate Transaction service to generate these advice messages. The service does the following: - Invokes Generate Transaction Selection rules to select the relevant Generate Transaction profile. GPP uses this profile type to determine the type of message to generate. The profile can also determine a Transaction Generation Mapping message refinement rule. - Invokes Transaction Generation Mapping Selection rules to determine the relevant Generate Transaction profile. In this case, GPP uses this profile type to determine the multiple Transaction Generation Mapping message refinement rules. - Invokes selected Transaction Generation Mapping rules to determine additional transaction mapping. - Generates the outgoing advice message and links it to the corresponding original transaction. --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide • Routes the advice message to the appropriate processing workflow for continued processing and transmission. For more information about rules and profiles, see Business Setup and System Configuration. Note: Authorized GPP users can view all generated advice messages for transactions via the user interface. For more information, see the GPP Online Help. # 4.4.1.3 Email/Fax Notification During the various stages of the payment processing the advising rule is triggered. Banks can set rules conditions to invoke advices per message status (Complete), party (debit or credit customers), amount thresholds (to send advices above x amount), payment type (MOP, direction, message type and sub type). Customers are able to set the rule action to be Advice profile with all relevant information for the advice. The profile can hold: - Relevant customer for the advice, or the specific account - If the advice is relevant for the credit or the debit side of the payment - The contact information The Advising type selection rule (172) must have the advice type as the action, which is email or fax advice. When the rule is caught, GPP searches for all the Advice profiles in the database that are relevant to the selected advice type and tries to match the customers from the payment to the customers in the profiles (and accounts, if populated). Each profile caught invokes an advice through the selected interface, and multiple advices can be sent for the same payment. # To enable email notifications 1. From the Advising profile specify all advices (debit, credit) and their contact information to be generated for a specific account or party. Multiple advices can be defined for a specific account or party. 2. From the Advice Info section, select EMAILADV as the Advice type and Advice sub-type. 3. Select between credit or debit advice. 4. From the Contact Type field, select Email advice. The information populated in Contact details will be used in the sent email or fax. 5. In the Contact Details area, enter the email address where the advice will be sent. 6. Repeat steps 1 – 6 to add additional notifications. # To enable fax notifications 1. From the Advising profile specify all advices (debit, credit) and their contact information to be generated for a specific account or party. Multiple advices can be defined for a specific account or party. 2. From the Advice Info section, select FAXADV as the Advice type and Advice sub-type. 3. Select between credit or debit advice. 4. From the Contact Type field, select Fax advice. The information populated in the Contact details will be used in the sent fax. 5. In the Contact Details area, enter the fax number where the advice will be sent. Page 22 --- # 6. Repeat steps 1 – 6 to add additional notifications. # 4.5 Manual Handling The Advices Interface requires no specific manual handling. # 4.6 Business Setup and System Configuration GPP uses business setup and system configuration reference data to enable system operation, transaction processing, and UI functionality. # 4.6.1 Business Setup GPP uses business reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining business rules, a financial institution can tailor system behavior to specific business requirements. # 4.6.1.1 System Parameters The following table describes the business-related system parameters, which authorized users can change, that GPP uses to implement the Advices Interface. | Parameter Name | Description | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | ADVCTYPE Table | | | ADVC\_VEHICLE | Determines whether GPP generates an interface or non-interface message for the transaction | | SYSTEM\_NOTIFICATION | Determines whether GPP accesses the relevant Advices profile to populate fields, such as contact information, in the outgoing advice message | # 4.6.1.2 Profiles GPP uses profiles to determine how the system processes each transaction and payment-related message using the specific information associated with the transaction. # 4.6.1.2.1 Advices Profile The Advices profile enables a financial institution to define credit and debit advice messages. GPP generates and transmits these messages to notify a financial institution customer of various events that can occur during transaction processing. Each profile stores general information about the account owner and contact information for transmitting each advice message. The following table describes other relevant fields in the Advices profile. | Field Name | Description | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Advice Info | | | Advice Type | The type of advice message that GPP generates for the transaction. | | Advice Sub-Type | The sub-type of the advice message. | | Min Amount | The minimum transaction amount. GPP generates an advice message only if the transaction amount is greater than the defined amount. | --- # Field Name # Description Advice Indicator The transaction party for which GPP generates an advice message. One of the following: - Credit Advice - Debit Advice - Fee Advice For more information about profiles, see the GPP Online Help. # 4.6.1.3 Rules At various points during the transaction processing workflow, GPP invokes business rules to determine continued transaction processing and handling. # 4.6.1.3.1 Advising Type Selection Rules GPP invokes this type of rule to determine whether to generate an advice message at a specific point in the workflow. If GPP determines that a transaction meets the criteria of a defined rule, GPP uses the value in the Advising Profile field of the rule to access the ADVCTYPE database table. For more information, see Details. For more information about advice message types, see Advices Interface Message Types and Non-Interface Message Types. For more information about business rules, see the GPP Online Help. # 4.6.2 System Configuration GPP uses system reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining system reference data, GPP can tailor system behavior to specific financial institution requirements. Note: GPP supplies a full set of system reference data that is customized to specific financial institution requirements. In most cases, authorized GPP users can view, but not update, system reference data. # 4.6.2.1 System Parameters The Advices interface requires no specific system parameters. # 4.6.2.2 Profiles GPP uses system profiles to determine how the system processes each transaction and payment-related message using the specific information associated with the transaction. # 4.6.2.2.1 Generate Transaction Profile The Generate Transaction profile enables GPP to define the types of advice messages to generate and transmit for a transaction. GPP generates and transmits these advice messages to notify a financial institution customer of various events that can occur during transaction processing. GPP invokes Generate Transaction Selection and Transaction Generation Mapping Selection rules to determine the relevant Generate Transaction profile for each transaction. The profile can also determine additional Transaction Generation Mapping message refinement rules. For more information, see Details. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 24 --- # 4.6.2.3 Rules At various points during the transaction processing workflow, GPP invokes system rules to determine continued transaction processing and handling. # 4.6.2.3.1 Generate Transaction Selection Rules GPP invokes Generate Transaction Selection rules to determine the relevant Generate Transaction profile for a transaction. If a transaction meets the criteria defined in a rule, GPP uses the value in the Transaction Profile field in the rule type to determine relevant Generate Transaction profile for a transaction. For more information, see Generate Transaction Profile. # 4.6.2.3.2 Transaction Generation Mapping Rules GPP invokes Transaction Generation Mapping rules to populate advice message fields with specific transaction attributes and other information. This rule type is a message refinement rule, which GPP invokes to populate and update specific transaction attributes and related fields with required values and other information. For more information, see the GPP Online Help. # 4.6.2.3.3 Transaction Generation Mapping Selection Rules GPP invokes Transaction Generation Mapping Selection rules to determine the relevant message refinement rule for a specific transaction. If a transaction meets the criteria of a defined rule, GPP uses the value in the Rule Action field of the rule to determine the appropriate Transaction Generation Mapping message refinement rule for the transaction. For more information, see the GPP Online Help. # 4.7 Message Data The Advices interface requires no specific message attributes. # 4.7.1 Audit Trail Entries The Advices interface requires no specific Audit Trail entries. # 4.7.2 Error Codes The Advices interface requires no specific error codes. # 5 Balance Inquiry Interface # 5.1 Overview Balance checking is performed in GPP to determine whether the debit account on a transaction has sufficient liquidity to allow the transaction to be released/completed. Note: Balance Inquiry is not performed for Asset Accounts. The HOST system is responsible for: - Evaluating the account liquidity, which may include the account’s net balance as well as credit lines and limits granted to the account. An account’s liquidity may also take into account the balance of a group of accounts. --- For placing a hold on the funds when a positive response is returned (if supported by HOST). The response may provide current balance information for the account, and an earmark reference, if hold was placed on the funds. While GPP may receive an actual Balance value from the HOST, GPP allows the HOST system to make the decision as to whether or not there is sufficient liquidity to release the transaction. The HOST system is responsible for placing a hold on the customer’s funds (providing it includes support for this type of hold) and when an approval is sent to GPP to release a transaction. It can be called in a mode with an expectation that the HOST will place a hold on funds, or can be used in an ‘inquiry only’ mode. This interface is always called within the context of a transaction. Pending a response to the Balance Inquiry, and if the interface is working in A-sync mode, the transaction is placed in Wait Balance Inq. Response (BIWAITQ) status. Balance Inquiry response may be positive, negative or not final. Where the response is negative, it is also possible to state the reason for failure. GPP is capable of setting the GPP message status (msg sts) and where the transaction should park (whether it is Repair, Insufficient Funds, Posting Restrictions or any pre-defined message status). When the Balance Inquiry is done in the Balance Inquiry with Earmark mode, GPP provides support for earmark release upon transaction cancellation or major change in the transaction details when submitted after repair. The HOST system uses this request to un-earmark intraday the funds held at the time of the Balance Inquiry from GPP. This interface, when configured to work in Earmark mode, can be defined to implement the GPP Synchronous Interface capability to prevent discrepancies between GPP and the external system, if a system error occurs during external interface request and response processing. For more information, see the GPP Interfaces Technical Guide. GPP supports a GPP Standard Balance Inquiry format that is suggested to be used for this interface. For more details on this format, see GPP Technical Guide - Fndt Message Usage for Balance Inquiry Interface. GPP can also support a proprietary format as per financial institution’s preference, once initial mapping effort is included between the proprietary format and the GPP attributes, and as long as the necessary information exists in this proprietary format. The GPP Balance Inquiry interface also supports Open API Balance Inquiry and Balance Inquiry with Earmark requests and responses for Finastra’s Fusion Essence system. For more information, see Fusion Essence System Support. # 5.2 Processing # 5.2.1 Balance Check Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 26 --- # 5.2.1.1 Workflow ( u) (∃ u) ooc t w o ooot t y wi o cimtn him Res RY HRre RS te e + ooem (∃ u) oonbe tu (spj s so doje) pese pun Adoo Ood d s PTTRT an tae PEEEEEEER Set (ual ed s!4) ao eoc e pecond Aes ee no J Mo oe POSSSSSTT PEEEEEX usgd on s J bsod POC ON MAASXAA Jddr FEOFE S1 pus pecee Reder uose on PNS SAuSE o pus cuiiiin Ceauel Ses se esuodse uoe o Raedr aae isdin spun ON buod ON ttciiin t (d=2s) resuodse (N=) s Sgsssssnd ON ON resuodse (emms) Rader .Ni il. jo ioj o1 pus Sess tiw Se juqns pu me bessc (an ns) ebn duemetn Weeen rn uo Ji re Mi me e an wo.j ON seodsd oiibe. eu Resend pose pun do FwMillg GAk kwod Maag g c nujunn PeS puno ON inbe unbeg BadSsesg g Ceeeee e Br ssdg EIeneI D ihue hunbue saaeg fene # 5.2.1.2 Handling Balance Inquiry Request During payment processing, GPP makes Balance Inquiry calls in the context of an individual transaction, which may be performed asynchronously or synchronously, as per the interface configuration. This interface is not used by an operator performing an online Balance Inquiry on an account. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 27 --- # Balance Inquiry The Balance Inquiry is performed on the debit account during the Analysis phase of processing. This occurs after debit and credit account selection and validation, and more specifically after Fees evaluation and before the external FX call. # Modes of Balance Inquiry - Balance Inquiry with Earmark: HOST system checks the customer’s funds availability and, if funds are sufficient, places a hold on the customer’s funds. - Inquiry Only: HOST system checks the account’s funds availability without placing a hold on the funds. Note: The GPP Balance Inquiry interface also supports Open API Balance Inquiry and Balance Inquiry with Earmark requests and responses for Finastra’s Fusion Essence system. For more information, see Fusion Essence System Support. # Interface Selection Rules Interface Selection rules are invoked to select the relevant Balance Inquiry interface. GPP can include in the request a unique 16-character Event ID each time the transaction triggers the Balance Inquiry interface (if using the GPP Standard Balance Inquiry format this ID is quoted in the Event ID tag within the Header section): - When an automatic or manual Retry is performed (due to negative or late response), the request is sent quoting a new event ID. - When it is a Force/Override request, the request is sent quoting a new Event ID. - When it is an Earmark Release, the request is sent quoting a new Event ID. - When it is a Resend, the request is sent quoting the original Event ID. The event ID is stored in the Message external interaction (EVENT_ID column), for interfaces that are configured to create a MESSAGE_EXTERNAL_INTERACTION entry, and the EVENT_ID_GENERATION field is set to 1 in their INTERFACE_TYPES entry. It is generated with the algorithm being similar to MID generation, including letters, numbers, and date & time, and it is saved, and can be used, in the D_MEI_EVENT_ID Logical Field. GPP stores the response in the Processing Communications (MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct so. Once a request is built, GPP sends it to the HOST, and the transaction is routed, when interface is A-sync, to the Wait Balance Inq. Response (BIWAITQ) status. # 5.2.1.2.1 Handling Balance Inquiry Response The HOST system should determine, based on the account number and the amount and date of the transaction, whether or not to respond with: - A successful response which is ‘make the transaction’; OR - A failure response which is ‘do not make the transaction’; OR - A non-final response Once a response is received in GPP: - GPP parses the response. - GPP validates that the response contains the required information and is structurally valid against the relevant defined structure, either the Standard Fndt Message or a financial institution specific proprietary structure per this interface type. - GPP performs matching between the response and the relevant request. For more details on the matching functionality see Response/Request Matching. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 28 --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide • GPP stores the response in the Processing Communications (MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct so. • Audit trail of the transaction is updated to indicate that a response was received. For a negative response, a response error description is also added to the message error log. Note: If the response contains multiple errors, GPP generates an error log entry for each error. • GPP evaluates the response value to decide to where it should route the transaction. See details in Successful Response, Non-Final Response, and Failure Response. • If the response is not received within a configurable timeout period, timeout will be retried per configured number of retries on the Interface Type, after which - Interface becomes inactive and Balance Inquiry request is treated as failed. For more details on Interface Timeout behavior, see GPP Technical Guide - Interfaces document # 5.2.1.2.2 Successful Response • A successful response is received (if using the Standard Fndt Message =1), meaning there is sufficient liquidity in the principal account to send the transaction. • GPP continues with processing of the message. • If additional information (earmark reference and/or balance) is provided in the Balance Inquiry response, GPP stores the information in the transaction data. • Later in the processing, while performing the posting step, if earmark reference was returned in the Balance Inquiry response, meaning hold was placed on the customer funds for this transaction, GPP uses it and returns it to the HOST system as part of the Posting request. • MI_BI_STS is set to P to indicate a successful balance check. # 5.2.1.2.3 Non-Final Response • A non-final response is received (if using the Standard Fndt Message =200), meaning that the request was received in the HOST system but additional investigations/manual handling in this system are required and therefore a final response will be sent later. Another reason for such a response might be that there are insufficient funds to send the transaction at the current time and the HOST is going to continue to wait for funding. - This type of response is used for an interface which is defined with a time out mechanism, in order to avoid reaching the maximum time out retries. - GPP is expecting the HOST to eventually send either a Failed or a Successful response. - GPP leaves the message in the Wait Balance Inq. Response (BIWAITQ) queue. - Interface time out counter is set to zero. # 5.2.1.2.4 Failure Response • The following responses are the options for failure response (if using the Standard Fndt Message is not 1 or 200): - Processing Error Response: - The HOST is unable to derive the requested account information due to a technical error. The Response is returned to GPP with a processing error response reason code and description of error. If a general error return code is received (return code 0) GPP routes the transaction to the Repair (REPAIR) queue. If technical return code is received (return code 990) the payment is either routed to the Stop queue (Inactive queue) or continues with the flow depending on the configured interface inactivity behavior. - Functional Failure Response - either of the following: - The HOST is unable to perform balance check because the account does not exist. The response is returned to GPP with a functional failure response reason code and description. GPP routes the transaction to a Repair (REPAIR) queue. Page 29 --- The HOST finds the account, but the account has posting restrictions on it. The HOST may return additional details about the specific posting restriction codes and description. GPP routes the transaction to the Posting Restrictions (POSTREST) queue. The HOST finds the account, but the account has insufficient liquidity to make the transaction. GPP routes the transaction to the Insufficient Funds (NSF) queue. - In this case GPP already prepares the transaction to an automatic retry, if not already breaching the maximum retries, by incrementing an attribute that counts the retries (P_RETRY_COUNT) and calculating the index attribute that will be used to select the transactions waiting for such retry, with the next time per the pre-configured frequency of retries. For more details see Automatic Retries. For any of the failure responses: - MI_BI_STS is set to N to indicate a non-successful balance check. Note: If the response contains multiple errors, GPP generates an error log entry for each error. # 5.2.2 Earmark Release # 5.2.2.1 Earmark Release Workflow | User Action (from any queue) | User Action (from Repair queue) | | ------------------------------------- | ------------------------------------------------ | | Cancel | Change message details and Submit | | Continue Earmark Cancelation flow | ~~No~~ | | Check threshold of previously placed? | Debit Amount ~~Yes~~ changed? | | More than accepted? | | | Yes | Yes | | Create earmark release request | Continue flow HV flow | | Response received | | | Yes | Successful response? | | No | Follow Up flag set to NEG\_BI\_RSPNS\_A FTR\_RLS | --- # 5.2.2.2 Details # 5.2.2.2.1 Handling Earmark Release Request When the Balance Inquiry is done in the Balance Inquiry with Earmark mode, GPP provides support for earmark release during transaction cancellation flow, or if major transaction details were changed as part of its repair. In a scenario, where a transaction is cancelled or changed in GPP after a successful balance response is received from HOST, and only when using the model of HOST placing a hold on the customer funds for this transaction (Balance Inquiry is done in the Balance Inquiry with Earmark mode), GPP can be configured to send an additional interface call in the Earmark Release mode. Earmark release is also triggered in cases where there are delivery failures on the outbound messages, for example, FED/CHIPS/SWIFT rejects. When the transaction involves currency conversion on the debit side, and the rate is set by the online FX interface or manually, the debit amount changes due to significant difference between the earmark done earlier in the process using the sheet rates. In this case, GPP evaluates the Update Earmark Request parameter, and based on its setting sends an Update Earmark request to update the debit amount. This request overrides the existing earmark with the updated one. Note: The GPP Balance Inquiry interface also supports Open API Balance Inquiry and Balance Inquiry with Earmark requests and responses for Finastra’s Fusion Essence system. For more information, see Fusion Essence System Support. The earmark release is invoked: - When a successful earmark hold response, quoting an Earmark Reference, was previously received, but posting for this amount is not yet performed. Note: When the earmark hold response was previously negative, no earmark release is required. When a successful response of Earmark mode was previously received, but no Earmark Reference was quoted in it – GPP regards this response as a BI response and no earmark release is required. The interface selection rule which selects Earmark Release should be configured based on the flow context (cancelation/reject and the P_BI_MAIN_EARMARK_REF in which the previously received Earmark Reference, if received, is quoted. The Earmark Release interface generates a request to the HOST system, quoting a new event ID and the previously received earmark reference (populated from the P_BI_MAIN_ERAMARK_REF or P_BI_FEE_ERAMARK_REF depending on the type of amount that was held and needs releasing (if using the Standard Fndt Message this is passed in the F_BI_INFO_EARMARK_REF tag). GPP stores the response in the Processing Communications (MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct so. The transaction does not park in a wait queue after sending the earmark release request. When a negative response is received, the Follow up flag is updated on the transaction entry with the value NEG_BI_RSPNS_AFTR_RLS. This Follow up flag can be used in a Custom filter rule to allow viewing the transaction in a separate Custom queue for monitoring. When a transaction is routed to Repair/Wait queue after Balance Inquiry, GPP triggers the Balance Inquiry when the transaction is released from the queue and submitted back to the high value flow. If relevant transaction attributes were changed (account, amount, and value date), an earmark release request and a new earmark hold request are sent, each quoting new Event IDs. In case the transaction moves to the manual repair queue after the Balance Inquiry process and earmarking the funds, GPP checks the Release Earmark on Repair system parameter and based on --- its value, issues a release earmark request. A new earmark request is generated when the transaction is repaired and submitted back to the flow. Note: A threshold is defined by which GPP should re-invoke the Balance Inquiry check. The threshold is defined in the Interface profile as a percentage. For example, threshold is defined as 10% and original check done on the amount of 100. If the new amount is up to 110 then re-invocation is not required. # 5.2.2.2.2 Handling Earmark Release Response - GPP parses the response. - GPP validates the response is structurally valid, against the relevant defined structure – either the Standard Fndt Message or a financial institution specific proprietary structure per this interface type, and contains the required information. - GPP performs matching between the response and the relevant request. For more details on the matching functionality see Response/Request Matching. - GPP stores the response in the Processing Communications (MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct so. - As the transaction was not waiting for the Earmark Release response, there is no special handling, but logging its arrival on the transaction level is performed, on either successful or failure responses. # 5.2.3 Automatic Retries Automatic retries are not performed for all types of interfaces. This section describes the automatic retries which are supported for the Balance Inquiry interface. | Gather transactions | NSF event | with | P\_RELEASE\_INDEX | Submit to the High Value flow | | ----------------------------------- | --------------------------------------------- | ---- | ----------------- | ----------------------------- | | (frequency as per NSF\_CHECK\_FREQ) | =NSF^HH:MM (as per EVENET\_ACTIVITIES record) | | | | When the message is in Insufficient Funds (NSF) queue (after an NSF response), GPP supports the functionality of limited automatic retries. The process is as follows: - The automatic triggering is based on a pre-defined frequency (usually set to 5 - 15 seconds), that is configured in the NSF_CHECK_FREQ system parameter. - When reaching the maximum number of retries, as pre-defined in the MAXNSFRETRY system parameter, GPP logs an error in the transaction’s error log, and the transaction remains in Insufficient Funds (NSF) queue. Note: - When a manual retry is performed using the Retry Insf. Funds button, before GPP stops its automatic retries (before MAXNSFRETRY number of retries), this retry is included in the count of retries before stopping. - The counting of retries is not interrupted or re-started in a scenario when the Business Date changes between retries. This means that if the maximum number of retries is 5, and after 3 retry attempts, all are still resulting in NSF responses, and the Business Date was advanced, GPP continues to retry only two more times before reaching the maximum and stopping the retries. GPP supports the functionality of limited automatic retries of the same request when the message is in Wait Balance Inq. Response (BIWAITQ) queue (waiting for a Balance Inquiry response), and the Balance Inquiry interface is configured to do so. --- Note: When configured as Balance With Earmark, GPP recommends not to configure the interface with automatic retries. # 5.2.4 Response/Request Matching In general, on Request/Response interfaces GPP supports matching methods (some functional and some technical) between the request, sent from GPP, and the response, received from the external financial institution system. - The functional, and more generic, method is the usage of and , quoting, in the response, their value/s from the request + the P_MID. - There are additional technical methods that allow echo back of the sending system (for example, GPP or a HOST channel) identifier in a custom property of the MQ header (the value of this identifier is captured from the request as transport property) or using the MQ correlation ID in the MQ envelope. Note: The Event ID is not currently used in the matching, therefore it is not mandatory to be returned in the response. # 5.2.5 Fusion Essence System Support GPP supports Open API Balance Inquiry requests and responses for Finastra’s Fusion Essence system. During processing, GPP accesses the IS_ESSENCE_BI system parameter (see System Parameters) when invoking the Balance Inquiry interface. If the parameter is set YES, GPP generates an Open API request that creates Balance Inquiry request, and transmits it to Fusion Essence in a synchronous mode. Upon receipt of a response from Fusion Essence, GPP continues with the generic Balance Inquiry workflow. Note: Finastra’s Fusion Essence solution is a core banking platform that enables banks to manage their total customer experience. For more information, see the relevant Finastra Fusion Essence documentation. # 5.3 Manual Handling This section describes the various scenarios in which a single transaction may be stopped in relation with the Balance Inquiry interface. - In a wait queue until the relevant response is received, or - In an inactive queue until the interface is active again, or - A manual queue due to information received in the response The description is per such specific manual queues. For a summary of actions per queue, see Appendix A: Manual Actions per Queues. # 5.3.1 Wait Queues # 5.3.1.1 Wait Balance Inq. Response (BIWAITQ) Queue A single transaction is stopped in this queue after an A-sync Balance Inquiry request is sent to the external system, and until a Balance Inquiry response is received. When using synchronous mode, the process is not stopped but waits for an online response, and the transaction is not parked in any queue. In this queue the following actions can be performed: Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 33 --- Force: Instructs GPP to continue processing a single or bulk of transactions even though no response was received. Only entitled users whose user profile maximum force limit amount is greater than the message amount can use this action button. - GPP Processing: - Transaction or bulk of transactions are released back to continue processing. Retry Bal. Inq.: Instructs GPP to retry the processing of a single or multiple message at once. - GPP Processing: - The CDB monitor is kept as P, if external Account Lookup is required and was performed earlier in the flow, to allow skipping an additional invocation of the Account lookup, when message is reprocessed. - When reaching the relevant point in the flow for Balance inquiry, and as the Balance Inquiry monitor is not set to P, as an indication that this step already ended successfully, GPP generates a new Balance Inquiry request to the HOST system, quoting a new event ID. The transaction is routed to Wait Balance Inq. (BIWAITQ) pending response from HOST system. Send to Repair: Instructs GPP to send the message to the Repair (REPAIR) queue for manual adjustments. - GPP Processing: - The transaction is routed to the Repair (REPAIR) queue. Cancel: Instructs GPP to cancel a single or bulk of transactions. - GPP Processing: - The transaction(s) is routed to cancellation flow, including earmark release, when required, and reverse posting, when required (for example, if the Balance Inquiry is pending on the second leg (target debit account), and Posting was already performed on first leg). # 5.3.2 Inactive Queues When the relevant interface is not active or technical error response code 990 is received from the interface, GPP behaves according to the inactive behaviour set for this interface, as per the generic interfaces functionality (for more details see GPP Interfaces Technical Guide). For the interfaces that are configured with Non-active behavior of STOP_UNTIL_ACTIVE or PERMANENT_STOP, the inactive queues are where the transaction waits for the relevant interface to become active. # 5.3.2.1 Inactive BI (BI_STOP) Queue The Balance Inquiry is a way to stop a transaction earlier than when need to perform the actual Posting. It is therefore recommended, that the Balance inquiry interface is configured with the Non-active behavior of SKIP, so that, GPP can proceed with the processing without checking the balance when the interface is not active. If the financial institution still wants to stop the transaction at the Balance Inquiry step and wait until it is active, the interface can be configured with Non-active behavior of STOP_UNTIL_ACTIVE. In this case when the interface is down the transaction is visible to the user in the Inactive BI (BI_STOP) queue. If Non-active behavior is set to PERMANENT_STOP, after the interface becomes inactive, and even if gets active again, the transaction remains visible to the user in the Inactive BI (BI_STOP) queue. In this queue the users can perform Cancel or Force actions, same actions as the Wait Queues. GPP Processing: Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 34 --- The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required (for example, if the Balance Inquiry cannot be performed on the second leg (target debit account), and Posting was already performed on first leg). # 5.3.3 Manual Handling Queues # 5.3.3.1 Posting Restrictions (POSTREST) Queue A single transaction may be stopped in this queue following a negative Balance Inquiry response with posting restrictions/limitations on the account or the customer (meaning that a valid Stop Flag existing in GPP is quoted as the reason for the failure). In this queue the following actions can be performed: - Override: Instructs to override the restriction (only active for a message that was stopped due to an overridable Stop Flag), and return the message to continue the processing. GPP Processing: - The relevant CDB monitor is kept as P, if external Account Lookup is required and was performed earlier in the flow for this account, to allow skipping an additional invocation of the Account lookup, when message is reprocessed. - The MU_STOP_FLAGS_OVERRIDE_STS is set to O, to indicate that the posting restriction was overridden, and processing continues from this point in the flow. - When reaching again the point of Balance Check, but only if the BI monitor is not P (it can be P if the transaction was routed to this queue later in the flow due to a Posting response), Balance inquiry interface generates a new request to the HOST system, quoting a new event ID, and indicating that the restriction was overridden (if using the Standard Fndt Message - MU_STOP_FLAGS_OVERRIDE_STS = O is quoted in the added Monitors extension). In Balance Inquiry with Earmark mode, the transaction is routed to Wait Balance Inq. Response (BIWAITQ) pending response from HOST system. - Later in the flow, once reaching the point of Posting – this request includes the additional information of the user decision to override posting restriction, either specifically quoting the MU_STOP_FLAGS_OVERRIDE_STS monitor as O, or providing a more general force indication, for all posting entries, which is relevant for both user actions of posting restriction override and force NSF (if using the Standard Fndt Message - F_POSTING_INFO_FORCE_POST_IND=1). - Sets the transaction status to the Approve Override queue and routes it to the Approve Override queue for additional manual handling. The override action must be approved or cancelled by another authorized GPP user or the same user who initiated the action, as per workflow definitions. The user can cancel the transactions in bulk. - Retry Post. Rest.: Instruct to retry the processing of a single or multiple messages at once GPP Processing: - The CDB monitor is kept as P, if external Account Lookup is required and was performed earlier in the flow, to allow skipping an additional invocation of the Account lookup, when message is reprocessed. - When reaching again the point of Balance Check, but only if the BI monitor is not P (it can be P if the transaction was routed to this queue later in the flow due to a Posting response), Balance inquiry interface generates a new request to the HOST system, quoting a new event ID. The transaction is routed to Wait Balance Inq. (BIWAITQ) pending response from HOST system. - Send to Repair: Instructs GPP to send the message to the Repair (REPAIR) queue for manual adjustments GPP Processing: - The transaction is routed to the Repair (REPAIR) queue. - Cancel: Instructs GPP to cancel the message Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 35 --- # 5.3.3.2 Insufficient Funds (NSF) Queue A single transaction may be stopped in this queue following a negative Balance Inquiry response with an indication of no sufficient funds in the account. In this queue the following actions can be performed: - Force Ins. Funds: Instructs GPP to continue processing even though the debit account has insufficient funds. Only entitled users whose user profile maximum force limit amount is greater than the message amount can use this action button. - GPP Processing: - Balance inquiry interface generates a new request to the HOST system, quoting a new event ID, and indicating that the user allows transaction processing to continue even though the account has insufficient funds (if using the Standard Fndt Message - MU_NSF_FORCE_STS = 1 within the added Monitors extension). - Later in the flow, once reaching the point of Posting, this request includes the additional information of the user decision to force the processing even with no sufficient funds in the account. Either specifically quoting the MU_NSF_FORCE_STS monitor as 1, or providing a more general force indication, for all posting entries, which is relevant for both user actions of posting restriction override and force NSF (if using the Standard Fndt Message F_POSTING_INFO_FORCE_POST_IND=1). Retry Ins. Funds: Instructs GPP to perform the Balance Inquiry interface call again. The user can perform retry process for a single or multiple messages at once. - GPP Processing: - Transaction is submitted back to try reprocessing again, eventually triggering another invocation of Balance Inquiry. Interface generates a new request to the HOST system, quoting a new Event ID. The transaction is routed to Wait Balance Inq. (BIWAITQ) pending response from HOST system. Send to Repair: Instructs GPP to send the message to the Repair (REPAIR) queue for manual adjustments. - GPP Processing: - The transaction is routed to the Repair (REPAIR) queue. Cancel: Instructs GPP to cancel the message. # 5.3.3.3 Repair Queue A single transaction may be stopped in this queue, in relation with interfaces, following a Balance Inquiry response with failure status that is not one of the specific Posting Restrictions or Insufficient Funds, or due to technical failures handling any of interfaces’ responses. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 36 --- In this queue the following actions can be performed: - Make amendments to the transaction details and Submit it for re-processing. # GPP Processing: - When reaching the point/s of Account Lookup - If the relevant CDB monitor is not set to P, to indicate a successful Account Lookup, or if the relevant account was updated by the user, an additional invocation of the Account lookup for the relevant account is triggered. - When reaching the point of Balance Check - If the BI monitor is not set to P (meaning that it was stopped before or due to a Balance Inquiry response), the Balance Inquiry interface is triggered. - If this monitor is P, to indicate a successful Balance Inquiry, but the Posting monitor indicates failure, and if relevant transaction attributes were changed (account, amount, value date), and if working in Earmark mode, an Earmark Release request along with the new Balance Inquiry with earmark hold request are triggered, each quoting a new event ID. - When reaching the point of Posting the Posting interface is triggered. - The Posting entries are re-calculated and compared with previous entries not already marked as successful/reversed. If they are different (may happen when relevant transaction attributes (account, amount, value date) were changed), reversed posting entries are created for these non-final entries, along with the newly calculated entries. These are included in the Posting request/s and are sent, quoting a new Event ID. - Cancel: Instructs GPP to cancel the message. - The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required (if the Balance Inquiry failed on the second leg (target debit account), and Posting was already performed on first leg). Note: The Account Lookup on the credit account is performed on the account of the party that is first in the credit chain (after the GPP chain enrichment). If the Credit account was entered manually, while in the Repair queue, and needs to be validated via Account Lookup, it must quote the same first in chain account, as GPP does not take it into account for the credit Account Lookup. # 5.4 Business Setup and System Configuration # 5.4.1 Business Setup # 5.4.1.1 System Parameters These System Parameters are business parameters, which are related to the Balance Inquiry functionality, when it provides Stop Flags or limitations on the account or customer. | Name | Description | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ASAP\_POST\_REST\_C | Specifies whether to perform the stop flags check as soon as possible. | | HECK | Values: | | | * Yes - stop flags check is initially performed for debit and credit sides separately as soon as the relevant account is loaded, either from GPP or via Feeder Request. The final check for both sides is also performed, in this case, on the later point in the flow (as performed if the value is No). * No - consolidated stop flags check is performed for both sides later in the flow, after MOP selection, STP override rules, Fee calculation and Time Hold rules, but before sending future dated transactions to Scheduled queue. Default | --- # 5.4.1.1 Configuration Parameters | Name | Description | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | IS\_ESSENCE\_BI | Determines whether GPP transmits Open API Balance Inquiry requests to Fusion Essence (see Fusion Essence System Support). Possible values: • YES: GPP transmits API requests to Fusion Essence. • NO: GPP does not transmit API requests to Fusion Essence. | | MAXNSFRETRY | Defines the maximum count for insufficient funds check retries. After which an automated retry is not performed. | | NSF\_CHECK\_FREQ | Specifies the frequency, in milliseconds, that transaction in the Insufficient Funds (NSF) status re-checked. The frequency should not be less than the NSF task frequency as depicted in the EVENT\_DEFINITION.FREQUENCY\_IN\_MINUTES column. Example: 300,000 milliseconds equal to 5 minutes | | Update Earmark request | Determines the way GPP handles the transaction earmark when the debit amount gets updated due to new FX rate. If configured as, • Yes – GPP sends an earmark update request • No – GPP first sends a release earmark and then a new earmark request | | Release Earmark on Repair | Decides whether the earmark for transaction moved to Repair (manual) queues should be released or not. | # 5.4.1.2 Profiles GPP uses profiles to determine how to process each transaction and payment-related message using the specific information associated with the transaction. For more information about profiles, see the GPP Online Help. # 5.4.1.2.1 Stop Flags The Stop Flag profile is relevant whenever the Balance Inquiry response may provide Stop Flags or limitations on the account or customer. Stop Flag entries should be defined in GPP for each Stop Flag value that may be provided as a restriction in the Balance Inquiry response. Each of these Stop Flags may be set as overridable or as non-overridable. In the Posting Restrictions queue the Override option is available for the user only if the Stop Flag reported in the Balance Inquiry response is an overridable one. No such option is available if the message was stopped due to a non-overridable Stop Flag. # 5.4.1.2.2 User Codes | Reason Type | Reason Code | Reason Description | | ----------- | ------------------------- | ----------------------------------------------------------------------------- | | FOLLOWUP | NEG\_BI\_RSPNS\_AFTR\_RLS | Negative response received on earmark release during transaction cancellation | # 5.4.1.3 Rules # 5.4.1.3.1 Bypass Step Rules Bypass step with the sub type of Balance Inquiry may be set to bypass the invocation of the Balance Inquiry interface for scenarios when this check is not required as per specific financial institution requirements. For example, when the position of the debit account is managed in GPP (the Accounts entry exists and it is marked as Posting Keeping). --- # 5.4.1.4 Permissions Permissions need to be granted to users that need to configure the different business profiles and rules related to the Balance Inquiry interface. # 5.4.2 System Configuration # 5.4.2.1 System Parameters The Balance Inquiry Interface requires no specific business-related system parameters. # 5.4.2.2 Profiles These are the details of the required setup in GPP system profiles for the Balance Inquiry Interface. Note: For a detailed description of all the fields in the profiles, see GPP Online Help. # 5.4.2.2.1 Interfaces Relevant Interfaces entries should be configured for the Balance Inquiry interface request and response. - Balance Inquiry may be configured as a synchronous or an asynchronous interface (Wait behavior). For the a-synchronous mode only, the wait queue Wait Balance Inq. Response (BIWAITQ) is specified. - In both cases, an inactive behavior (SKIP, STOP_UNTIL_ACTIVE, PERMANENT_STOP or STORE) is defined. - As the Balance Inquiry is just a way to stop a transaction earlier than when need to perform the actual Posting, it is recommended that the Balance inquiry interface is configured with the non-active behaviour of SKIP, so that, GPP can proceed with the processing without checking the balance when the interface is not active. - If the financial institution still wants to stop the transaction at the Balance Inquiry step, the interface can be configured with non-active behaviour set to STOP_UNTIL_ACTIVE or PERMANENT_STOP, and Inactivity Status set to Inactive BI (BI_STOP) queue. - The context keyword in the Custom Properties of Interface Type entries of Outgoing requests should contain the value to send in the tag of the request message: - BalanceInquiry, BalanceInquiry_With_Earmark– are the options for the Balance Inquiry Interfaces entry. BalanceInquiry_With_Earmark is the default Product setup, but this parameter can be configured to BalanceInquiry per deployment for banks which their account balancing management system does not support earmarking. - EarmarkRelease – for the Interfaces entry of Earmark Release. - Additional technical definitions, for example, the connection point of the MQ queue used. For a description of the relevant fields, see the GPP Online Help or the GPP Interfaces Technical Guide. Note: When the Fndt Message format is defined as the structure to use for a specific interface type, GPP can also be setup to control which sections of the generic Fndt Message structure are to be sent out for this Request/Response, from a maximum with a full structure (including all the message related attributes), to a minimum specific per interface type. For example, for Balance Inquiry interface only the section quoting the balance check information. # 5.4.2.2.2 Event Management The event NSF should be set for the automated retry task. | Event Name | Event Description | Mode | Minutes | Batch Size | | ---------- | ------------------------------- | ---- | ------- | ---------- | | NSF | Automatic Retry of NSF messages | 0 | 10 | 1 | --- # Event Name # Event Description # Mode # Minutes # Batch Size The frequency of the task should be equal to or less than the setting of the NSF_CHECK_FREQ system parameter. # 5.4.2.3 Rules At various points during the transaction processing workflow, GPP invokes system rules to determine continued transaction processing and handling. # 5.4.2.3.1 Interface Selection Interface selection rules can be configured according to customer’s requirement, in order to select the relevant Balance Inquiry interface (Balance Inquiry with Earmark or Inquiry Only, and the Earmark Release scenario). # 5.5 Message Data There are no specific Message Attributes or Audit Trail entries for this interface. # 5.5.1 Error Codes The following table describes the error codes required by the GPP Balance Inquiry Interface. | Error Code | Description | | ---------- | ---------------------------------------------------------------------------------------------------- | | 0 | Error that does not require specific error handling. GPP routes the transaction to the Repair queue. | | 1 | Success | | 990 | Processing/Technical Error | | 995 | Insufficient Funds | | 996 | Posting Restriction | # 6 Compliance Interface # 6.1 Overview The Fusion Global PAYplus (GPP) Compliance Interface enables a financial institution to comply with various laws, rules, and regulations enacted by some countries and government organizations to prevent terror financing and money laundering. The interface enables these organizations, such as the United States Office of Foreign Assets Control (OFAC), to enforce economic and trade sanctions on relevant parties during transaction processing. The Compliance Interface enables a financial institution to verify that all incoming and outgoing transactions comply with all relevant laws and regulations. The interface communicates with an external financial institution compliance system to determine whether a transaction is in compliance with all relevant rules and regulations. It is an asynchronous process that enables GPP to generate an outgoing request to an external system, which validates a transaction for compliance. GPP can also receive and process the incoming responses returned by the external interface. GPP can invoke either of the following types of interfaces: - External: GPP invokes an external interface via the GPP Gateway, which is a proprietary GPP component designed and developed to provide a scalable platform to handle a variety of --- messaging formats when communicating with external interfaces and microservices. For more information, see the GPP Gateway Technical Guide and the GPP Interfaces over Gateway – Single Transactions Business Guide. - Internal: GPP invokes an internal interface for accounts managed within GPP. Interface responses and requests use the standard FuNDs Transfer (Fndt) Message format. For more information, see the GPP Fndt Message Usage for Compliance Interface Technical Guide. Note: The Fndt Message structure that GPP transmits to various GPP and other external interfaces, such as the Account Lookup interface, is static and not given to updates for internal format changes. GPP updates the structure only when these interfaces require additional attributes. The Compliance Interface over Gateway supports the following request and response structures: - Compliance Request: Outward from GPP to the financial institution host - Compliance Response: Inward to GPP from the financial institution host GPP triggers the Compliance interface at the following exit points in the single payment flow: - Before debit account derivation - Before Posting invocation - After cancellation # 6.2 Processing The Compliance interface in GPP triggers a call to an external system for transactions to be screened against current Sanction and Compliance lists. The Compliance interface can be triggered at three points in the single payment flow: - Predebit - Prior to debit side derivation - Preposting - Prior to the Posting invocation point, which is before completion of the incoming transaction or sending out of outgoing transaction. - After cancellation- Configurable step, which is activated upon payment cancellation from UI. In general, the predebit point is used for incoming transactions and the preposting point for outgoing transactions. Incoming and Onward transactions trigger the Compliance check at both points. After Cancellation point is used in the transaction where manual cancellation is applicable, and this point is configurable. Triggered in case that in Country preferences of the payment's country the flag "Mandatory ofac screening" is checked. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 41 --- # 6.2.1 Predebit and Preposting Invocation Point # 6.2.1.1 Workflow | Sanctions Flow | SWIFT/Clearing/ | GPP | Interface | External Sanctions System | | ------------------- | --------------- | ------------------ | --------- | ------------------------- | | CREATE | Payment | Payment Processing | | | | WAIT\_OFAC | Request | | | | | ~~User~~ Action | Force | Response | External | Sanctions System | | Continue Processing | Hit | Failure/Invalid | Resend | OFAC\_POSS | | ~~User~~ Action | IBLE\_HIT | Cancel | | | # Cancellation Flow | No Hit | Response | Second Response | | ------------------- | -------------- | -------------------- | | | Type | Failure/Seized Funds | | Continue Processing | Approved | OFAC\_HIT | | REPAIR | Seized | Cancel (Outgoing) | | User Action | Send to Repair | | # Return (Incoming) # Return Flow # 6.2.1.2 Details 1. GPP invokes the Compliance validation business rule in order to determine whether a transaction should be sent to Compliance check. - Rule action is derived from a pre-defined field value (where Field type is COMPLIANCE_CHECK). - Rule action can be set as BYPASS, indicating this transaction should bypass the Compliance check. 2. GPP invokes the Interface selection rule to apply the relevant interface. 3. GPP generates the Compliance request, which can use the proprietary customer specific structure, or the standard Fndt Message structure, and routes the transaction to Wait OFAC queue, pending a response. 4. When the initial response is received, GPP evaluates the return code provided in the response: - Return code is No Hit: The transaction passed the screening with no hit. The transaction continues to be processed. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 42 --- # Return Codes and Transaction Processing - Return code is Possible Hit: The transaction had a possible hit and is under investigation within the external Compliance system. GPP routes the transaction to OFAC Possible Hit queue with the relevant error. The transaction waits in this queue pending a second response. - Return code Technical Error (return code 990): The payment is either routed to the Inactive queue or continues to the next step, depending on the inactivity behavior configured on the interface. # 5. When the second response is received, GPP evaluates the return code provided in the response: - Return code is No Hit: The transaction continues to be processed. - Return code is Hit: GPP routes the transaction to the Compliance Exception queue. - Return code is Seized Funds: GPP changes automatically the Credit account to a special suspense seizing account- either the default Seize account configured in the Currency profile, or another selected later on in the flow through the Destination Account selection rules, changes the MOP to BOOK, processes the transaction, including the Posting (funds taken into the suspense account), and finally routes the transaction to the Seized queue. - Return code Technical Error (return code 990): The payment is either routed to the Inactive queue or continues to the next step, depending on the inactivity behavior configured on the interface. # 6. If the response is not received within a configurable timeout period, timeout will be retried per configured number of retries on the Interface Type, after which - Interface becomes inactive and Compliance request is treated as failed. For more details on Interface Timeout behavior, see GPP Technical Guide - Interfaces document. --- # 6.2.2 Cancellation Invocation Point # 6.2.2.1 Workflow # Cancellation Flow | Channel/Gpp user/ | GPP | GPP Queues | External interface | | ------------------------------------------- | ------------------------------- | -------------------------- | ------------------ | | Clearing | Manual queue | | | | Payment initiation | Payment | allowing cancellation | | | User performs | cancel | User performs | Refuse | | Approve | Cancel | User performs | Cancel | | WAIT\_OFAC | | | | | 1st Compliance Request | | | | | Initial response | ~~1~~st~~ Compliance Response~~ | External Compliance System | | | Hit | OFAC\_POSSIBLE\_HIT | 2nd Compliance Request | | | No Hit | Final response | | | | ~~Hit/No HIT~~ | | Cancelled | Seized | | Update credit account to the Seized account | | | | # 6.2.2.2 Details 1. GPP checks the value of flag “Mandatory OFAC Screening” in the country preferences profile of the country of local office. If it is checked, then the OFAC step upon cancellation is triggered. Otherwise, the payment performs cancellation as per BAU without OFAC check. 2. GPP invokes the Interface selection rule to apply the relevant interface. 3. GPP generates the Compliance request, which can use the proprietary customer specific structure, or the standard Fndt Message structure, and routes the transaction to Wait OFAC queue, pending a response. 4. When the initial response is received, GPP evaluates the return code provided in the response: - Return code is No Hit: The transaction passed the screening with no hit. The transaction moved to cancelled. - Return code is Possible Hit: The transaction had a possible hit and is under investigation within the external compliance system. GPP routes the transaction to OFAC Possible Hit queue with the relevant error. The transaction waits in this queue pending a second response. --- # 5. When the second response is received, GPP evaluates the return code provided in the response: - Return code is No Hit: The transaction is cancelled. - Return code is Hit: GPP routes the transaction to cancellation. - Return code is Seized Funds: GPP changes automatically the Credit account to a special suspense seizing account- the default Seize account configured in the Currency profile, changes the MOP to BOOK, processes the transaction, including the Posting (funds taken into the suspense account), and finally routes the transaction to the Seized queue. # 6.2.3 Response/Request Matching In general, on Request/Response interfaces GPP supports matching methods (some functional and some technical) between the request, sent from GPP, and the response, received from the external financial institution system. - The functional, and more generic, method is the usage of <ContecName> and <contexLocalName>, quoting, in the response, their value/s from the request + the P_MID. - There are additional technical methods that allow echo back of the sending system (for example, GPP or a HOST channel) identifier in a custom property of the MQ header (the value of this identifier is captured from the request as transport property) or using the MQ correlation ID in the MQ envelope. Note: The Event ID is not currently used in the matching, therefore it is not mandatory to be returned in the response. # 6.3 Manual Handling This section describes the various scenarios in which a single transaction may be stopped in relation with the Compliance interface. # 6.3.1 Wait Queues # 6.3.1.1 Wait OFAC Queue (WAIT_OFAC) A single transaction is stopped in this queue when it is waiting for an initial response from the Compliance interface. In this queue the following actions can be performed: - Processing Communications: Opens the Processing Communications page to allow instructing to resend the interface request. - GPP Processing: - - The Processing Communications page is opened for the user to resend the interface request, quoting the same event ID (if exists). The user can resend a single or bulk of transactions at once. Force: Instructs GPP to continue processing the transaction as if no hit was detected. - GPP Processing: - - The transaction is processed as if a no hit response is received. Reject/Return: Opens a new transaction page in order to create a related Outgoing Return transaction. This is relevant for Incoming transactions only. - GPP Processing: --- # 6.3.2 Inactive Queue GPP Processing: - Force: Instructs GPP to continue processing a single or bulk of transactions even though no response was received. Only entitled users whose user profile maximum force limit amount is greater than the message amount can use this action button. Once the response is received, the message is routed to the relevant approval queue. Single transaction or bulk of transactions are released back to continue processing. - Cancel: Instructs GPP to cancel the transaction. GPP Processing: - The transaction is routed to cancellation flow, including earmark release or reverse posting, whenever required. # 6.3.3 Manual Handling Queues # 6.3.3.1 OFAC Possible Hit Queue (OFAC_POSSIBLE_HIT) A single transaction is stopped in this queue when the transaction received a Hit in the initial response from the Compliance interface. In this queue the following actions can be performed: - Force Release: Declines the Possible Hit and instructs GPP to continue processing the transaction as if no hit was detected. - GPP Processing: - The transaction is processed as if a no hit response is received. Cancel: Instructs GPP to cancel the transaction. - GPP Processing: - The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required. Reject/Return: Opens a new transaction page in order to create a related Outgoing Return transaction. This is relevant for Incoming transactions only. - GPP Processing: - A new transaction page is opened for users to input required data and submit. The outgoing return is processed to completion to be sent out. When return is in Complete, original transaction is routed to Returned queue. Retry: Instructs GPP to re-submit a single or multiple transactions at once for processing. --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide # 6.3.3.2 Compliance Exception Queue (COMPEX) A single transaction is routed from OFAC Possible Hit queue to this queue when a transaction received a Hit in the second response from the Compliance interface. In this queue the following actions can be performed: - Reject/Return: Opens a new transaction page in order to create a related Outgoing Return transaction. This is relevant for Incoming transactions only. - GPP Processing: - A new transaction page is opened for users to input required data and submit. The outgoing return is processed to completion to be sent out. When return is in Complete, original transaction is routed to Returned queue. Send to Repair: Instructs GPP to send the transaction to the Repair (REPAIR) queue for manual adjustments. If required, the original credit account can be manually replaced with a suspense account. - GPP Processing: - The transaction is routed to the Repair (REPAIR) queue. Cancel: Instructs GPP to cancel the transaction. - GPP Processing: - The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required. Force Release: Used to force the release of a message as not a compliance hit. - GPP Processing: - Forces the release of a message from the Compliance Exception queue as not a compliance hit. Retry: Instructs GPP to re-submit a single or multiple transactions at once for processing. # 6.3.3.3 Repair Queue (REPAIR) A single transaction may be stopped in this queue, when receiving a Processing/Technical error in the second response from the Compliance interface. In this queue the following actions can be performed: - Make amendments to the transaction details and Submit it for re-processing. - GPP Processing: - To replace the Credit Account with a Suspense Account for seizing the funds Cancel: Instructs GPP to cancel the transaction. Page 47 --- # 6.4 Business Setup and System Configuration # 6.4.1 Business Setup # 6.4.1.1 System Parameters There are no specific System Parameters, which are business parameters, required for the Compliance Interface. # 6.4.1.2 Profiles GPP uses profiles to determine how to process each transaction and payment-related message using the specific information associated with the transaction. # 6.4.1.2.1 Currency Profile The Seized Funds Suspense Account field is used to define the default credit account to be used when a Compliance response of Hit and Seize (return code 2) was received, or the user used the Block button in the Compliance Exception queue. Later in the flow, this account might be overridden by the Destination Account Enrichment rule. Note: For a detailed description of all the profiles, see GPP Online Help. # 6.4.1.3 Rules # 6.4.1.3.1 Compliance Validation Rule This business rule defines at which exit point the system triggers the compliance check for a transaction. The recommended setup is to use the predebit point for incoming transactions and the preposting point for outgoing transactions. Incoming and Onward transactions trigger the Compliance check at both points. The business rule should be based on the transaction direction (Debit/Credit MOPs) and the OFAC interface monitors; OFAC Predebit status and OFAC Preposting status. This is an example of the rule setup. The final setup should be done by the Financial Institution. | Rule Attribute | Setup Guidelines | | ----------------------------- | -------------------------------------------------------------------------------- | | Rule Name | COMPLIANCE\_PREDEBIT | | Rule Sub Type (Relation Type) | 0 | | Description | Rule to trigger the PREDEBIT compliance check (incoming and onward transactions) | | Attachment | \*\*\* | | Rule conditions | \[Dbt MOP] <> BOOK And \[OFAC Predebit sts] = P | | Rule Action | SANCTIONS | | Rule Attribute | Setup Guidelines | | ----------------------------- | ---------------------- | | Rule Name | COMPLIANCE\_PREPOSTING | | Rule Sub Type (Relation Type) | 0 | --- # Rule Attribute # Setup Guidelines Description: Rule to trigger the PREPOSTING compliance check (outgoing and onward transactions) Attachment: *** Rule conditions: [Cdt MOP]<> BOOK And [OFAC Preposting sts] = P Rule Action: SANCTIONS Form this scenario and example the following Compliance Bypass rule should be attached at a lower hierarchy than the Compliance Predebit and Compliance Preposting rules, in order that it is applied if neither of the two were applied. # Rule Attribute # Setup Guidelines Rule Name: COMPLIANCE_BYPASS Rule Sub Type (Relation Type): 0 Description: Rule to bypass compliance Attachment: *** Rule conditions: Rule Action: BYPASS # 6.4.1.3.2 Destination Account Enrichment Rule This business rule allows overriding the default Seize funds. Suspense account configured in the Currency profile for a case funds need to be seized, when the transaction continues the flow till completion. The business rule should be based on the Monitor indicating the instruction for seizing (MU_COMPLIANCE_FORCE_STS). # 6.4.2 System Configuration # 6.4.2.1 System Parameters There are no specific System Parameters, which are system parameters, required for the Compliance Interface. # 6.4.2.2 Profiles The Compliance Interface requires no specific system profiles. # 6.4.2.3 Rules # 6.4.2.3.1 Interface Selection Rule Interface selection rules can be configured according to customer’s requirement, in order to select the relevant Compliance interface. # 6.4.2.3.2 Repair and Enrichment Rule The Repair and Enrichment rule is configured to replace the credit account with the Seized funds suspense account and to set the MOP as BOOK. The rule bases in its conditions on the Monitor indicating the instruction for seizing (MU_COMPLIANCE_FORCE_STS). --- # 6.5 Message Data There are no specific errors and audit trails for this interface. Possible values of statuses for OFAC Predebit Interface monitor and OFAC Preposting Interface monitor: - B - Bypassed - N - No Hit - H - Hit - S - Possible Hit - W - Wait (Set when a payment moves to Wait queue) - Z - Seized (Not currently used) - R - Rejected (May be used in case of a Processing/Technical error) - P - Pending (Set when a request is sent) - E - Error (May be used in case of a Processing/Technical error) # 7 Feeder Interface # 7.1 Overview This interface can be used by a Feeder system to handoff all types of single payment transactions, including: - Book transfers: transferring funds between two customers who maintain accounts in the same financial institution. - Account transfer: transferring funds between a customer/financial institution who has different accounts in the same financial institution (for example, liquidity sweeps) - Charge billing: debit customer account, credit financial institution PNL account - High value domestic transaction - High value international transaction - Single low value domestic transaction - Outgoing transaction instruction GPP supports a GPP Standard Feeder format that is suggested to be used for this interface. For more information on this format, see GPP Technical Guide - Fndt Message Usage for Feeder Interface – Single Transaction. GPP can also support a proprietary format as per the financial institution’s preference. It is only supported, once the initial mapping effort is included between the proprietary format and the GPP attributes, and as long as the necessary information, per the different options, exists in this proprietary format. --- # 7.2 Processing # 7.2.1 Workflow Parsing and Capturing transaction and additional information provided # HV Flow Processing # FX Handling | Resent for FX Handling triggered by event | Trigger Rate | | ----------------------------------------- | ----------------------------------------------- | | WAIT\_TRIGGER\_RATE | received and is favorable over calculated rate? | | Failed processing | No | | Use calculated rate | Yes | | Change details | Wait for better rate | | Submit | User Acknowledgment | | Repair | Action | | Wait Rate | Canceled | # 7.2.2 Handling the Feeder Request GPP parses and captures the information from the message. It then submits it to the relevant processing flow (typically the single high value business flow). # 7.2.2.1 Parsing GPP parses the tags and fields of supported message types (for example, pain.001, pain.008 and MT103). # 7.2.2.2 Capturing and Storing Persistent Processing Information and Monitors GPP captures and store the processing persistent information and, if provided, the monitors information provided by the Feeder system. If using the Standard Fndt message, these are passed within these extensions: ProcessingPersistentInfo and Monitors. If using a financial institution’s proprietary format that can include such information, it is passed within the relevant fields in this structure. --- # Feeder system Transaction reference: - GPP captures the Feeder system’s transaction reference. If using the Standard Fndt message it is provided in the P_TX_ID tag (within ProcessingPersistentInfo extension). For more information on the usage of this attribute see Payment Source - GPP supports setting up multiple feeder systems and the ability to identify the different payment sources for operational and business needs. To support this the Feeder Payment Source List is used and enables customers to add the names of the various required payment sources, which are treated as the feeder source. A rule function replaces all rules that looked at PMNT_SRC=FEEDER to look at the Feeder Payment Source List instead. - Usage of Transaction Reference. # Suggested or instructed MOP: - If the transaction is a Credit Transfer, GPP captures the credit MOP. If using the Standard Fndt message it is provided in the P_CDT_MOP tag within this extension. In addition, GPP captures the MU_SET_CDT_MOP monitor, if provided, (within Monitors extension) to identify if the MOP is meant to be a suggested MOP or an instructed MOP. For more information on the usage of these attributes, see Usage of MOP Information. - If the transaction is a Collection (Direct Debit), GPP captures the debit MOP. If using the Standard Fndt message it is provided in the P_DBT_MOP tag within this extension. In addition, GPP captures the MU_SET_DBT_MOP monitor, if provided, (within Monitors extension) to identify if the MOP is meant to be a suggested MOP or an instructed MOP. For more information on the usage of these attributes see Usage of MOP Information. # Debtor and debit account (when provided): - If the debtor and debit account information is provided for an outgoing credit transfer, specifically in dedicated fields within the Feeder request (if using the Standard Fndt message it is passed in the ProcessingPersistentInfo extension), GPP captures this information as the debtor and debit account information for its processing. - If the debtor and debit account information is provided in the transaction payload (pain message), GPP captures it from this source and then derives the full debtor and debit account according to standard processing. - For more information on the usage of these attributes see Usage of Account and Customer Information. # Creditor and credit account (when provided): - If the creditor and credit account information is provided for an outgoing collection (direct debit), specifically in dedicated fields within the Feeder request (if using the Standard Fndt message it is passed in the ProcessingPersistentInfo extension), GPP captures this information as the creditor and credit account information for its processing. - If the creditor and credit account information is provided in the transaction payload (pain message), GPP captures it from this source and then derives the full creditor and credit account according to standard processing. - For more information on the usage of these attributes see Usage of Account and Customer Information. # Reverse Sell Indicator - GPP captures the Reverse Sell Indicator that is provided in P_RVS_SELL (if using the Standard Fndt message it is passed in the ProcessingPersistentInfo extension). - For more information on the usage of this attribute see Usage of Rates Related Information. # 7.2.2.3 Capturing and Storing Message Fees When the message fees information is provided within the Feeder request (if using the Standard Fndt message, within the extension MsgFees), GPP captures it and stores it so that it can be used in the processing of the message. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 52 --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide GPP first validates that the fee occurrences reported are per existing and valid Fee Types as defined in GPP. If valid, GPP populates the message fees structure in the PDO, and creates corresponding records in MSG_FEES table when the message is stored. # Table: Mapping of Fees Attributes to MSG_FEES Entries | To MSG\_FEES Field Name | Taken From | | --------------------------- | ------------------------------------------------------------------- | | MID | Current message P\_MID | | APPLY | F\_MSG\_FEES\_FEE\_APPLY | | MANUAL\_FEE | F\_MSG\_FEES\_MANUAL\_FEE = ‘CDB’ | | DEDUCT\_FROM | F\_MSG\_FEES\_DEDUCT\_FROM | | FEE\_ACC\_AMOUNT | F\_MSG\_FEES\_FEE\_ACC\_AMOUNT or calculated | | FEE\_AMOUNT | F\_MSG\_FEES\_FEE\_AMOUNT | | FEE\_AMOUNT\_IN\_PMT\_CCY | F\_MSG\_FEES\_FEE\_AMT\_IN\_PMT\_CCY or calculated | | FEE\_BASE\_AMOUNT | F\_MSG\_FEES\_FEE\_BASE\_AMOUNT or calculated | | FEE\_CURRENCY | F\_MSG\_FEES\_FEE\_CURRENCY | | FEE\_FORMULA\_UID | Set by GPP to ‘CDB’ | | FEE\_PNL\_ACCOUNT\_CURRENCY | F\_MSG\_FEES\_FEE\_PNL\_ACC\_CUR or retrieved from Fee type profile | | FEE\_PNL\_ACC\_NO | F\_MSG\_FEES\_FEE\_PNL\_ACC\_NO or retrieved from Fee type profile | | FEE\_PNL\_ACC\_OFFICE | F\_MSG\_FEES\_PNL\_ACC\_OFFICE or retrieved from Fee type profile | | FEE\_PNL\_AMOUNT | F\_MSG\_FEES\_FEE\_PNL\_AMOUNT or calculated | | FEE\_TYPE\_UID | F\_MSG\_FEES\_FEE\_TYPE\_UID | | ORIG\_FEE\_AMOUNT | F\_MSG\_FEES\_ORIG\_FEE\_AMOUNT or calculated | | PAYING\_PARTY | F\_MSG\_FEES\_PAYING\_PARTY | These fees are handled in the payment processing as CDB fees (fees calculated and received from an Account Management (CDB) system). - The message fees are associated a Dummy virtual fee formula with the following attributes: - Name & Description = CBD - Fee calculation method = Regular - Fixed fee method = Message - Percentage = 0 - GPP calculates and populates the various amounts (when needed) based on the fee amount; including: - Original fee amount - Fee amount in transaction currency - Fee amount in base currency - Fee amount in fee account currency - Fee amount in PNL account currency Page 53 --- # 7.2.2.3.1 Derivation of the P&L Account for Fees If the Feeder system cannot provide the Fee PNL account, the details of the account should be maintained on the Fee Type profile. GPP then retrieves these details from the Fee Type profile that should be provided in Feeder request (if using the Standard Fndt message, within the MsgFees element (F_MSG_FEES_FEE_TYPE_UID)). # 7.2.2.3.2 Derivation of the FEE Account Fee account is derived only if the fees are deducted from the account. GPP derives the fee account in the following order: 1. If the fee account is provided in the Feeder request within specific tags (if using the Standard Fndt message, within the ProcessingPersistentInfo extension), GPP uses it as the fee account. 2. If the fee account is provided in the Feeder request within the transaction payload (for example in pain.001, pain.008 in tag), GPP uses it as the fee account. 3. If the fee account is defined in the relevant Account profile, GPP uses it as the fee account. 4. If the fee account is defined in the relevant Parties profile, GPP uses it as the fee account. 5. If GPP cannot derive the fee account at any point in the process, GPP uses the principle account as the fee account. Note: During processing, if there is a fee enrichment rule, it will override all of the above and define the fee account. For more information on the usage of fee information see Usage of Fees Information. # 7.2.2.4 Capturing and Storing Message Rates When the message rates information is provided within the Feeder request, GPP captures it and stores it so that it can be used in the processing of the message. GPP uses the format of the inward payment message to determine the location of the message rates information as follows: - Standard Fndt Message: GPP derives the information from the MsgRates tag in the Extn tag of the message. - Pain.001 Message: GPP derives the information from the MsgRates tag that is nested under the new Supplementary Data (SplmtryData) tag. For information about Supplementary Data, see the GPP Supplementary Data Business Guide. GPP populates the message rates structure in the PDO, and creates corresponding records in the MESSAGERATES table when the message is stored. | To MESSAGERATES Field Name | Taken From | | -------------------------- | ---------------------- | | MID | Current message P\_MID | | CONTRACT | F\_FC\_CONTRACT | | AMOUNT | F\_FC\_AMOUNT | | CCY1 | F\_FC\_CURRENCY1 | | CCY2 | F\_FC\_CURRENCY2 | | SPREAD | F\_FC\_SPREAD | | SPREAD\_UNITS | F\_FC\_SPREAD\_UNITS | --- # To MESSAGERATES | Field Name | Taken From | | ----------------- | ------------------------ | | CONVERSION\_TYPE | F\_FC\_CONVERSION\_TYPE | | FORWARD\_CONTRACT | F\_FC\_FORWARD\_CONTRACT | | CUSTOMER\_ID | F\_FC\_CUSTOMER\_ID | | MANUAL\_SPREAD | F\_FC\_MANUAL\_SPREAD | | LATEST\_DATE | F\_FC\_LATEST\_DATE | | RATE\_DIRECTION | F\_FC\_RATE\_DIRECTION | Note: After populating the MESSAGERATES entry, GPP continues the currency conversion process using the same workflow that it uses for manually-entered rates. For more information on the usage of rate information see Usage of Rates Related Information. # 7.2.2.5 Capturing and Storing Earmark and Balance Information The balance information, if provided in the Feeder request within specific tags (if using the Standard Fndt message BICheckInfo extension), as a result of a balance and reservation check in the sending system, before handoff to GPP. The information may include earmark references and/or balance of the account. For more information on the usage of these attributes see Usage of Earmark Information. # 7.2.2.6 Additional Logging Note that in the case of a Feeder interface the Product configuration on the Interface entry is to not store the request in the Processing Communications (MESSAGE_EXTERNAL_INTERACTION table), as this would be a redundant duplicate to the logging of messages as it was received, including additional extensions if provided, in the MINF column of XML_Orig_Msg, that is also visible in the UI in the Before window on the message screen. # 7.2.3 Usage of Information Received During Processing # 7.2.3.1 Payment Source GPP supports setting up multiple feeder systems and the ability to identify the different payment sources for operational and business needs. To support this, the Feeder Payment Source List is used and enables customers to add the names of the various required payment sources, which are treated as the feeder source. A rule function replaces all the rules that looked at the PMNT_SRC=FEEDER to look at the Feeder Payment Source List. # 7.2.3.2 Usage of Transaction Reference - GPP includes this reference (within P_TX_ID tag) in the acknowledgement/status report sent to the Feeder system, as a result of advising. - GPP may also need to use a transaction reference to match a cancelation request to a transaction. # 7.2.3.3 Usage of MOP Information Once reaching the MOP Selection step: - If the transaction is a Credit Transfer, GPP uses the captured Credit MOP in the P_CDT_MOP during processing. - When the MU_SET_CDT_MOP monitor is also provided (within Monitors extension) with the value of F, this MOP is regarded by GPP as an instructed MOP (same as a manually selected MOP by the user). GPP does not invoke the MOP selection logic, and only performs MOP Validation on this MOP. - When this monitor is not provided, or is provided with a different value, the provided MOP (in P_CDT_MOP) is regarded by GPP as a suggested MOP. The MOP selection rules are --- invoked. These rules can be configured to include a condition on the provided P_CDT_MOP, and hence influence the final MOP selected by these rules. - If the transaction is a Collection (Direct Debit), GPP uses the captured Debit MOP in the P_DBT_MOP during processing. # 7.2.3.4 Usage of Account and Customer Information - Debtor and debit account (when provided): - GPP loads additional debtor and debit account information needed for processing from the relevant Party and Account profiles, if managed in GPP, according to standard processing. This is done regardless of the source, within the Feeder request (specific tags or the transaction payload), in which the debtor and debit account information is provided for an outgoing credit transfer. - Creditor and credit account (when provided): - GPP loads additional creditor and credit account information needed for processing from the relevant Party and Account profiles, if managed in GPP, according to standard processing. This is done regardless of the source, within the Feeder request (specific tags or the transaction payload), in which the creditor and credit account information is provided for an outgoing collection (direct debit). # 7.2.3.5 Usage of Fees Information Once reaching the Fee Calculation step: - If fees information is provided and is captured within the MSG_FEES table as CDB fees (fees calculated and received from an Account Management (CDB) system), GPP uses the fees as provided for the specific Fee Types, (skipping the calculation of fees for these types), and only adds fees of other Fee Types, if configured and found per the specific transaction. # 7.2.3.6 Usage of Rates Related Information Once reaching the FX Rate Calculation step, if relevant: - If rates information is provided and is captured within the MESSAGERATES table, GPP uses the rate information as provided per the different scenarios specified in Forward Contract, Counter Rate and Spread, and Trigger Payment. - For all scenarios GPP handles a foreign exchange transaction according to the Reverse Sell Indicator that is provided and captured in P_RVS_SELL. - When the Reverse Sell Indicator is set to 1, GPP handles it as a Reverse Sell (fixed debit amount). - When the Reverse Sell Indicator is not set to 1 or is not present, GPP handles it as standard (fixed credit amount). # 7.2.3.6.1 Forward Contract In a scenario when MsgRates element is received with F_FC_FORWARD_CONTRACT_TYPE set to 0, GPP treats the rate received in the F_FC_RATE tag as the final rate that is applied to the transaction, unless the rate expiration is quoted in F_FC_LATEST_RATE tag and is earlier than the current business date. When this rate is valid, the GPP rates and spreads are not used. --- # 7.2.3.6.2 Counter Rate and Spread - If the F_FC_LATEST_DATE tag quotes an earlier date than the current business date, the transaction is sent to the FX Rate Repair queue. Note: if no F_FC_LATEST_DATE is provided, the transaction continues processing, and the contract never expires. - F_FC_SPREAD and F_FC_SPREAD_UNITS may be included in the MsgRates element for informational display. Even if they are included, they will not be used in the currency calculation when the F_FC_FORWARD_CONTRACT = 0. Note: Rate Usage profile can be the same one used for non-contract transactions, as the contract data overrides any other settings. - If transaction is stopped, for example in Repair or NSF, or any other manual or wait queue, GPP goes back through the FX conversion process, and uses the contract rate again. The F_FC_LATEST_DATE is also rechecked against the current business date at that point. # 7.2.3.6.3 Trigger Payment - In another scenario in which MsgRates element is received with F_FC_FORWARD_CONTRACT_TYPE set to 3, and a rate is included in the F_FC_TARGET_RATE tag (instead of the F_FC_RATE tag). - GPP calculates the rate, based on GPP rates, using the contract spread received within the MsgRates element (F_FC_SPREAD and FC_SPREAD_UNITS). - GPP then compares the calculated rate to the Target rate, but only if Latest Date is not earlier than current business date. - If the GPP calculated rate is favorable or equal to the Target rate, this rate is used to execute the transaction. - If the calculated rate is higher (more expensive for the customer) than the Target rate, the transaction is routed to Wait FX queue (P_FC_INFO_IND is set to T). - From this queue a retry mechanism (based on an event WAIT_TRIGGER_RATE) invokes a re-calculation of the rates per this transaction, and again the comparison to the Target rate is performed. - If the Latest date is reached without achieving the Target rate, GPP calculated rates with the contract spread and this rate is used to execute the transaction. # 7.2.3.6.4 Rate Direction When a rate is received with this indicator, GPP uses it to know whether to multiply the amount to convert by the rate, or to divide it. When the value is: - D - Direct conversion - Multiply the amount by the rate - I - Indirect conversion - Divide the amount by the rate This is used in tolerance validation to make sure GPP does not fail the tolerance validation when an external rate is received (whether through feeder or external FX engine). --- # 7.2.3.7 Usage of Earmark Information The earmark reference information, if provided, is used when creating posting entries for this message, and it is quoted in the posting entries sent out in the Posting Request. This field, if not empty, can also be used in the BI Bypass rule, if it is not necessary to do an additional Balance Check (additional to the one performed in the sending system prior to handoff to GPP). If the Balance Inquiry is not skipped, when such a reference already is quoted, the reference needs to be sent within the Balance Inquiry request, to allow matching and releasing of the old reference in the financial institution’s system. # 7.2.4 Response/Acknowledgment Initiation The GPP advising mechanism is responsible for providing a response message on transaction initiation, as well as for providing advises on the progress of the transaction (including crediting and debiting the customer account). One of the supported options within this mechanism is to provide the sending system the structure of the Fndt message as an advice. In this case GPP includes the Feeder system reference number (P_TX_ID), if received within the Feeder Request in the Fndt message (Feeder response) advice. The Advice initiation can be configured to be invoked when transaction reaches various statuses (Advising Type Selection rules are invoked every time the process stops, meaning that whenever the transaction is stopped on a manual, waiting or final status). See details on recommended configuration in Advising Type Selection. # 7.3 Manual Handling This section describes the various scenarios in which a single transaction may be stopped after being handed off via a Feeder request: - In a wait queue until the relevant response is received, or - A manual queue due to information received from an interface The description is per such specific manual queues. For a summary of actions per queue, see Appendix A: Manual Actions per Queues. # 7.3.1 Wait Queues # 7.3.1.1 Wait Rate (WAITRATE) Queue A single transaction is stopped in this queue whenever it is waiting for an up-to-date rate. In relation with the Feeder interface, this can occur when the Feeder request provided a Target Rate, and the computed GPP rate was not favorable to this Target Rate. In this case, the transaction is routed to this queue to wait for an automated release and retry via the WAIT_TRIGGER_RATE event. # 7.3.2 Manual Handling Queues # 7.3.2.1 Repair Queue A single transaction may be stopped in this queue, due to functional or technical failures, when handling the Feeder request or the transaction itself. In this queue the following actions can be performed: - Make amendments to the transaction details and Submit it for re-processing. - Cancel: Instructs GPP to cancel the message. GPP Processing: - The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required, depending when in the flow it is routed to Repair. --- # 7.4 Business Setup and System Configuration # 7.4.1 Business Setup # 7.4.1.1 System Parameters There are no specific System Parameters, which are business parameters, required for the Feeder Interface. # 7.4.1.2 Profiles The Feeder Interface requires no specific GPP profiles. # 7.4.1.3 Business Rules # 7.4.1.3.1 Advising Type Selection The Advising Type Selection rules should be configured for the scenarios in which a notification is required to be created and sent back to the Feeder system as a response. These rules are invoked whenever the transaction is stopped in a manual, waiting or final queue. The recommended configuration is the following, but any financial institution can decide to configure less or more than these notifications. A recommended set of notification can be provided when transaction reaches the following statuses: - A success advise with ACTC in the <TxSts> of the created pain.002 – when transaction reaches COMPLETE, WAIT_ACK or WAIT_CONFIRMATION Note: rules can restrict a double success invocation in case of State=COMPLETE and Previous Status is either of WAIT_ACK or WAIT_CONFIRMATION, in which case a success notification was already sent for an outgoing transaction. - An advise informing on a Pending state with PNDG in the <TxSts> of the created pain.002 – on the first time the transaction is written into the GPP DB (Previous Status is RECEIVED) and transaction reaches the different wait and manual queues - WAITCOMPLIANCECHECK, CDBWAIT, BIWAITQ, POSTREST, NSF, POSTEX or REPAIR. - A failure advise with RJCT in the <TxSts> of the created pain.002, when transaction reaches CANCELLED, RETRUNED, REJECTED or NAK. # 7.4.1.4 Permissions Permissions need to be granted to users that need to configure the rules related to the Feeder interface. # 7.4.2 System Configuration # 7.4.2.1 System Parameters There are no specific System Parameters, which are business parameters, required for the Feeder Interface. # 7.4.2.2 Profiles These are the details of the required setup in GPP system profiles for the Feeder Interface. Note: For a detailed description of all the profiles, see GPP Online Help. # 7.4.2.2.1 Interfaces Relevant Interfaces entries should be configured for the Feeder interface request and for the Acknowledgment (ACK) notification that serves as a response. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 59 --- As the Feeder request is an Incoming interface, there is no relevancy for Inactive behavior configuration, as when interface is down nothing will be received from it. For a description of the relevant fields, see the GPP Online Help or the GPP Interfaces Technical Guide. Note: When the Fndt Message format is defined as the structure to use for a specific interface type (Standard), GPP can also be setup to control which sections of the generic Fndt Message structure are to be sent out for this Request/Response, from a maximum with a full structure (including all the message related attributes), to a minimum specific per interface type. For example, for Feeder interface only the sections quoting the transaction text and a few ProcessingPersistentInfo attributes. # 7.4.2.2.2 Event Management The event WAIT_TRIGGER_RATE should be set to release up to 10 transactions from the Wait Rate (WAITRATE) queue every 5 minutes. Note: There is another WAITRATE event that is triggered when a user updates the exchange rate profile. | Event Name | Event Description | Mode | Minutes | Batch Size | | ------------------- | --------------------------------------- | ---- | ------- | ---------- | | WAIT\_TRIGGER\_RATE | Retry transactions with FX trigger rate | 0 | 5 | 10 | # 7.4.2.3 Rules # 7.4.2.3.1 Interface Selection Interface Selection rules, selecting the relevant Interfaces entries, should be configured for the Feeder interface request and for the Acknowledgment (ACK) notification that serves as a response. # 7.5 Message Data There are no specific message attributes, errors and audit trails for this interface. # 8 Fees Interface # 8.1 Overview The GPP Pricing mechanism invokes specific services that enable a financial institution to derive accurate and applicable fees and charges for each transaction during transaction processing. The Pricing mechanism supports both the following methods of fee calculation: - Internal: GPP handles all fee calculations internally as part of the generic transaction processing workflow. For more information, see the GPP Pricing Business Guide. - External: GPP supports external financial institution fees interfaces. During transaction processing, GPP generates and transmits a request to an external Fees interface. GPP can receive and process the inward response returned by the external interface. - Manual: The GPP User Interface enables authorized users to calculate all relevant fees. For more information, see the GPP Online Help. GPP supports an external Fees Interface for various transaction and payment message types. For more information, see Supported Transaction Types to Supported Transaction Types. # 8.2 Interface Modes GPP invokes the Fees Interface in either of the following modes: Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 60 --- • Asynchronous: GPP uses this mode during transaction processing to calculate all relevant fees for a transaction. GPP generates and transmits an interface request and routes the transaction to the Wait Fees Response queue (see Wait Fees Response (FEE_WAIT) Queue). Upon receipt of a response, GPP matches the inward response with the appropriate request and continues processing. • Synchronous: GPP uses this mode when an authorized user clicks the Presubmit button on the User Interface, which enables the user to validate all relevant fees for a specific transaction before submitting the actual fees. GPP generates and transmits an interface response and, upon receipt of a response, displays all received fees in the relevant User Interface fields. For more information, see the GPP Online Help. # 8.3 Supported Transaction Types The external Fees Interface supports the following transaction types: - Bank to Bank: GPP transfers funds between two banks. - Inward Credit Transfer: GPP receives an inward credit transfer from clearing. - Inward Return Message: GPP receives an inward Return message from clearing. - Outward Customer Credit Transfer: GPP receives an outward credit transfer from a customer. - Outward Financial Institution Credit Transfer: An authorized user manually creates an outward credit transfer via the GPP User Interface. - Outward Return: An authorized user manually creates an outward Return message via the GPP User Interface. # 8.4 Processing Before GPP invokes the internal Pricing mechanism, it accesses the EXTERNAL_FEE system parameter (see System Parameters), which GPP uses to determine whether to invoke either of the following: - Internal Mechanism: If the parameter is defined for the internal mechanism, GPP continues with the internal Pricing mechanism as part of the generic transaction processing workflow. For more information, see the GPP Pricing Business Guide. - External Interface: If the parameter is defined for the external Fees Interface, GPP invokes the external Fees Interface. For more information, see Details. # 8.4.1 Details After invoking the GPP Fees Interface, GPP invokes Interface Selection rules (see Interface Selection Rules) to determine the interface mode, either asynchronous or synchronous, as described in Interface Modes. GPP invokes the Fees Interface in asynchronous mode during transaction processing to calculate all relevant fees for a transaction. GPP generates an interface request in the Standard Fndt Message format. For more on the format, see the GPP Fndt Message Usage for Fees Interface Technical Guide. GPP then transmits the interface request to the financial institution’s fees interface. After transmitting the request, GPP sets the transaction status to FEE_WAIT and routes it to the Wait Fees Response queue (see Wait Fees Response (FEE_WAIT) Queue). Note: If the interface is offline, GPP sets the transaction status to FEE_STOP and routes it to the Inactive Fees queue until the interface comes online. --- # 8.4 Response Handling Upon receipt of a response, GPP matches the inward response, which must be in the standard Fndt Message format, with the appropriate request (see Response/Request Matching). The response can be either of the following: - Positive: Upon receipt of a positive response, GPP parses the response and does the following: - Matches the response to the original transaction or payment message by invoking Matching Check Profile Selection rules. For more information, see the GPP Online Help. - If the response contains fees, GPP does the following: - Stores all received fee information in their corresponding payment message attributes. - Generates relevant Audit Trail entries. - Routes the payment message to the generic message processing workflow, including posting as required. - If the response does not contain fees, GPP routes the transaction to the generic message processing workflow for continued processing. - Negative: On receiving the negative response, GPP sets the transaction status to REPAIR and routes it to the Repair queue for manual handling (see Repair (REPAIR) Queue). In case technical error is received (return code 990) the payment status is either set to FEE_STOP then it is routed to the Inactive queue or proceeds with the payment processing, depending on the inactivity behavior configured on the interface. # 8.4.1 Synchronous Processing GPP invokes the Fees Interface in synchronous mode if an authorized user clicks the Presubmit button on the User Interface. This mode enables a user to validate all relevant fees for a specific transaction before submitting the actual fees. In this mode, GPP generates and transmits an interface response and, upon receipt of a response, displays all received fees in the relevant User Interface fields. # 8.4.2 Response/Request Matching In general, on Request/Response interfaces GPP supports matching methods (some functional and some technical) between the request, sent from GPP, and the response, received from the external financial institution system. - The functional, and more generic, method is the usage of and , quoting, in the response, their value/s from the request + the P_MID. - There are additional technical methods that allow echo back of the sending system (for example, GPP or a HOST channel) identifier in a custom property of the MQ header (the value of this identifier is captured from the request as transport property) or using the MQ correlation ID in the MQ envelope. Note: The Event ID is not currently used in the matching, therefore it is not mandatory to be returned in the response. # 8.5 Manual Handling This section describes the various scenarios in which GPP might route a single transaction to a manual handling queue during processing in relation with the Fees Interface. GPP can route a transaction to one of the following types of queues: - Manual Handling: An authorized user can access transactions in these queues for manual handling. For more information, see Manual Handling Queues. - Wait: GPP routes transactions to these queues to wait for some other pending action. For more information, see Wait Queues. --- # 8.5.1 Manual Handling Queues # 8.5.1.1 Repair (REPAIR) Queue GPP can route a transaction to the Repair queue for manual handling. An authorized user can access individual transactions in this queue and click one of the following buttons: - Cancel: Instructs GPP to cancel the transaction, and depending on specific workflow definitions, does one of the following: - Sets the transaction status to CANCELLED and routes it to the Cancelled queue. - Sets the transaction status to APPROVE_CANCEL queue and routes it to the Approve Cancel queue for additional manual handling. The cancel action must be approved by another authorized GPP user or the same user who initiated the action, as per workflow definitions. - Submit: Instructs GPP to submit the transaction for processing after the user updates transaction details. - Reject/Return: Instructs GPP to open a new transaction page that enables the user to create a related outward Return transaction. The user can submit the outward Return, which GPP processes to completion at which time GPP sets the original transaction status to RETURNED and it to the Returned queue. Note: Reject/Return is relevant only for inward transactions. # 8.5.2 Wait Queues GPP routes transactions that are waiting for a response from an external interface or system in Wait queues. An authorized GPP user can access individual transactions in these queues to perform manual actions. # 8.5.2.1 Inactive Fees (FEE_STOP) Queue During transaction processing, if the Fees Interface is offline, GPP sets the transaction status to FEE_STOP and routes it to this queue until the interface comes online, after which GPP continues processing the transaction. # 8.5.2.2 Wait Fees Response (FEE_WAIT) Queue After transmitting a request to the external Fees Interface in asynchronous mode, GPP routes each transaction to the Wait Fees Response queue until GPP receives a request response from the financial institution’s fees interface. An authorized user can access individual transactions in this queue and click one of the following buttons: - Send to Repair: Instructs GPP to set the transaction status to REPAIR and to route it to the Repair queue for manual handling. - Cancel: Instructs GPP to cancel the transaction, and depending on specific workflow definitions, does one of the following: - Sets the transaction status to CANCELLED and routes it to the Cancelled queue. - Sets the transaction status to APPROVE_CANCEL queue and routes it to the Approve Cancel queue for additional manual handling. The cancel action must be approved by another authorized GPP user or the same user who initiated the action, as per workflow definitions. - Reject/Return: Instructs GPP to open a new transaction page that enables the user to create a related outward Return transaction. The user can submit the outward Return, which GPP processes to completion. --- processes to completion at which time GPP sets the original transaction status to RETURNED and it to the Returned queue. Note: Reject/Return is relevant only for inward transactions. - Retry: Instructs GPP to re-submit a single or multiple transactions at once for processing. A request is generated for each payment, and payment waits for the response in the same (Wait Fee) queue. # 8.5.3 Inactive Queue When the relevant interface is not active or a technical negative response is received (return code 990), GPP behaves according to the inactive behaviour set for this interface, as per the generic interfaces functionality (for more details see GPP Interfaces Technical Guide). For the interfaces that are configured with Non-active behavior of STOP_UNTIL_ACTIVE or PERMANENT_STOP, the transaction waits in the inactive queues, for the relevant interface to become active. # 8.5.3.1 Inactive Fees (FeeSTOP) Queue If the Fee interface Non-active behavior is setup as STOP_UNTIL_ACTIVE or PERMANENT_STOP and when the interface goes down or technical error response is received (return code 990), the transaction is visible to the user in the Inactive Fee (FeeSTOP) queue. In this queue users can perform Cancel and Send to Repair actions. # GPP Processing: - Cancel: The transaction is routed to cancellation flow, including earmark release, (for example, if the Account Lookup cannot be performed on the target credit account, while Balance Inquiry on the debit account already took place), or reverse posting, whenever required (for example, if the Account Lookup cannot be performed on the target credit account, while Posting on the debit leg already took place). - Send to Repair: Sends the payment to Repair status. # 8.6 Business Setup and System Configuration GPP uses business setup and system configuration reference data to enable system operation, transaction processing, and User Interface functionality. For more information, see the GPP Online Help. # 8.6.1 Business Setup The GPP Fees Interface requires no specific business setup. # 8.6.2 System Configuration GPP uses system reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining system reference data, GPP can tailor system behavior to specific financial institution requirements. Note: GPP supplies a full set of system reference data that are customized to specific financial institution requirements. In most cases, authorized GPP users can view, but not update, system reference data. --- # 8.6.2.1 System Parameters The following table describes the system parameters that GPP uses to implement the Fees Interface. | Parameter Name | Description | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | EXTERNAL\_FEE | Determines whether GPP invokes the internal fees mechanism or external Fees Interface. Possible values: • Yes: GPP invokes Interface Type Selection rules to determine the external Fees interface mode. • No: GPP invokes the internal fees mechanism. | # 8.6.2.2 Profiles GPP uses system profiles to determine how the system processes each transaction and payment-related message using the specific information associated with the transaction. # 8.6.2.2.1 Interfaces Profile The Interfaces profile stores definitions about how GPP interacts and communicates with external systems. The GPP Fees Interface requires relevant Interfaces profiles, which should be configured for the Fees Interface. For a description of the relevant fields, see the GPP Online Help or the GPP Interfaces Technical Guide. Note: When GPP is defined to use the Fndt Message format structure for a specific interface type, GPP can also be set up to define which sections of the structure to send. This definition can be a maximum with a full structure (including all the message related attributes), to a minimum that is specific per interface type. For example, for Account Lookup Interface only the sections quoting details of the account, customer and contacts. # 8.6.2.3 Rules At various points during the transaction processing workflow, GPP invokes system rules to determine continued transaction processing and handling. For more information, see the GPP Online Help. # 8.6.2.3.1 Interface Selection Rules The GPP Fees Interface invokes Interface Selection rules to determine the most appropriate Interfaces profile for each transaction. For more information, see the GPP Online Help. # 8.7 Message Data There are no specific Message Attributes, errors and audit trails for this interface. # 9 Fraud Interface # 9.1 Overview The GPP Fraud Interface enables GPP to verify that transactions comply with all relevant anti-fraud rules and regulations as enforced by a financial institution’s external fraud interface or by using a third-party service provider via Service Provider Interface (SPI) over FFDC. --- The Fraud Interface generates and transmits an outgoing request to the fraud interface (either the financial institution’s external interface or the SPI interface) and routes the transaction to a specific queue until receipt of a response from the fraud interface. GPP uses the response (successful or failure) received from the financial institution’s interface to determine continued transaction processing. If the financial institution does not have its own fraud system, it can opt for Service Provider Interface (SPI). This SPI which is provided by the third-party service provider integrates with the GPP. # 9.2 Fraud Interface for Single Payments Using Financial Institution’s Fraud System # 9.2.1 Processing GPP invokes the Fraud Interface at specific exit points during the transaction processing workflow. A financial institution can determine which transactions require fraud validation by defining business rules to bypass or invoke the Fraud Interface for specific transaction types. For more information, see Business Setup and System Configuration. For Inward Immediate Payments, the Fraud Check (First and Second steps) can be controlled by the respective system parameters: - FRAUD_CHECK (First step) – - True - the Fraud Validation is performed before the Account Lookup step. - False - the Fraud Validation step is skipped. - FRAUD_CHECK_STEP2 (Second step)– - True - the Fraud Validation is performed after the Account Lookup step. - False - the Fraud Validation step is skipped. If both parameters are set as True, then the second Fraud Validation step is auto skipped if first Fraud Validation step is performed successfully. # 9.2.1.1 Workflow The following shows the Fraud Interface workflow. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 66 --- Fraud validation rule | Wait\_Fraud | Invoke | Action? | Bypass | | ------------- | ---------------- | ------------- | ------------------- | | Fraud sts = W | Fraud interface | Fraud sts = B | | | Y | Initial response | Pass | Fraud sts = P | | Hold | Wait Fraud | Fraud sts = H | Continue processing | | Fail | Final response | Pass→ | Fraud sts = P | | Fail | | \* | Fraud sts = F | # 9.2.1.2 Details As part of the generic transaction processing workflow, GPP invokes the Fraud Interface during individual transaction processing after the Message Duplicate Check flow and before invoking the Account Lookup Interface (see Account Lookup Interface). GPP invokes this interface also at the end of the flow before posting (pre-posting). GPP determines whether to invoke the interface using the Fraud Validation business rules. If a transaction meets the conditions of a defined rule, GPP uses the value defined in the Send Payment to field to determine whether to invoke the interface. The field can contain one of the following values: - BYPASS: If a transaction meets the conditions of a rule defined with this value, GPP does not invoke the Fraud Interface for the transaction and does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to B - Routes the transaction to the generic transaction processing workflow for continued processing - FRAUD1: If a transaction meets the conditions of a rule defined with this value, GPP invokes the Fraud Interface for the transaction. If GPP determines to invoke the Fraud Interface for a transaction, GPP does the following: - Generates an outgoing interface request in the required format - Transmits the request to the financial institution's external fraud interface - Sets the transaction with a WAIT_FRAUD status and routes it to the Wait Fraud queue Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 67 --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide # Transaction Processing in GPP GPP holds the transaction in the Wait Fraud queue pending receipt of a corresponding response from the financial institution’s interface. GPP can receive and process the following response types: # Response Types # PASS The response contains a Return Code of 1, which indicates the transaction successfully passed the financial institution’s fraud validations. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to P - Generates a Transaction passed Fraud scan Audit Trail entry for the transaction - Routes the transaction to the generic transaction processing workflow for continued processing # HOLD The response contains a Return Code of 2, which indicates the pending arrival of an additional response from the external interface. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to H - Generates a Hold received Fraud scan Audit Trail entry for the transaction - Move transactions to FRAUD_POSSIBLE_HIT status until receipt of the second response, which can be either a PASS or FAIL, as previously described. # FAIL The response contains a Return Code of 0, which indicates the transaction did not pass the financial institution’s fraud validations. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to H - Generates a Transaction failed Fraud scan Audit Trail entry for the transaction - Sets the transaction status to FRAUDEX and then routes it to the cancellation flow for transaction cancellation Note: A financial institution can define specific business rules that GPP uses to notify the initiating party of a failed fraud validation. If a transaction meets the conditions of a defined rule, GPP generates and transmits a Notification message that contains a reason for the failure. For more information about business rules, see the GPP Online Help. # TECHNICAL FAILURE The response contains a Return Code of 995, which indicates that GPP did not perform the financial institution’s fraud validations. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to E - Generates a Technical Error received from Fraud scan Audit Trail entry for the transaction - Retains the transaction in the FRAUDEX queue Until receipt of a corresponding response from the external interface, an authorized GPP user can access individual transactions in the Wait Fraud queue to perform a manual action, which GPP uses to determine continued transaction processing. For more information, see Wait Fraud (WAIT_FRAUD/FRAUD_STOP) Queue. # Exceptions - Interface Offline: If the Fraud Interface is offline, GPP sets the transaction with a FRAUD_STOP status, which requires manual handling. - Technical Issue: If GPP is not able to invoke the Fraud Interface because of a technical issue, an authorized GPP user can resend or cancel the transaction. For more information about manual handling, see Manual Handling. All transaction updates from the Fraud Interface generate relevant Audit Trail entries. For more information, see Audit Trail Entries. Note: If a failure response contains multiple errors, GPP generates an error log entry for each error. Page 68 --- # 9.2.2 Response/Request Matching In general, on Request/Response interfaces GPP supports matching methods (some functional and some technical) between the request, sent from GPP, and the response, received from the external financial institution system. - The functional, and more generic, method is the usage of <ContecName> and <contexLocalName>, quoting, in the response, their value/s from the request + the P_MID. - There are additional technical methods that allow echo back of the sending system (for example, GPP or a HOST channel) identifier in a custom property of the MQ header (the value of this identifier is captured from the request as transport property) or using the MQ correlation ID in the MQ envelope. Note: The Event ID is not currently used in the matching, therefore it is not mandatory to be returned in the response. # 9.2.3 Manual Handling In various transaction processing scenarios, GPP might route a transaction to a manual handling queue after invoking the Fraud Interface. Authorized GPP users can access individual transactions in these queues to determine additional transaction processing. # 9.2.3.1 Inactive Queues The Fraud Interface requires no specific Inactive queues. # 9.2.3.2 Manual Queues The Fraud Interface requires no specific Manual queues. # 9.2.3.3 Wait Queues GPP routes transactions that are waiting for a response from an external interface or system in Wait queues. An authorized GPP user can access individual transactions in these queues to perform manual actions. # 9.2.3.3.1 Wait Fraud (WAIT_FRAUD/FRAUD_STOP) Queue After invoking the Fraud Interface, GPP routes a transaction to the Wait Fraud queue pending a corresponding interface response. An authorized user accesses individual transactions in this queue and can click one of the following: - Return: For incoming messages only, clicking Return invokes transaction generation of a return message. Sets the monitors (Cancel), the message goes to the WAITRETURN status until the return reaches complete, then the status changes to returned. - Cancel: Clicking Cancel instructs GPP to cancel the transaction, and depending on specific workflow definitions, does one of the following: - Sets the transaction with a CANCELLED status and routes it to the Cancelled queue. - Sets the transaction with an APPROVE_CANCEL queue and routes it to the Approve Cancel queue for additional manual handling. The cancel action must be approved by another authorized GPP user or the same user who initiated the action, as per workflow definitions. GPP also sets the MU_FRAUD_FORCE_STATUS to C and enables the GPP user to select either the CUST error code or the TX FRAUD error code. - Force: For transactions with a WAIT_FRAUD status only, clicking Force indicates that the transaction has successfully passed the fraud validation and instructs GPP to continue processing the transaction. --- GPP also sets the MU_FRAUD_FORCE_STATUS to A and generates an Audit Trail entry (see Audit Trail Entries) to indicate the GPP user who initiated the action. In addition, the MF_FRAUD_VALIDATION_STS set to F. When processing a transaction, if the Fraud Interface is offline, GPP sets the transaction with a FRAUD_STOP status and routes it to the Wait Fraud queue. A GPP user can access the transaction when the interface comes online and click Resend to return the transaction to the transaction processing workflow, which includes a request to the Fraud Interface, for continued processing. Note: GPP users can resend a request via the GPP Processing Communication page, which they can access from the Transaction Data page. For more information, see the GPP Online Help. # 9.2.4 Business Setup and System Configuration GPP uses business setup and system configuration reference data to enable system operation, transaction processing, and UI functionality. # 9.2.4.1 Business Setup GPP uses business reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining business rules, a financial institution can tailor system behavior to specific business requirements. # 9.2.4.1.1 System Parameters FRAUD_CHECK - this system parameter indicates if the Fraud Check is part of the Single Transactions flow. When this system parameter is set to Yes, then the Fraud validation rule is invoked. # 9.2.4.1.2 Profiles The Fraud Interface requires no specific GPP profiles. # 9.2.4.1.3 Rules At various points during the transaction processing workflow, GPP invokes business rules to determine continued transaction processing and handling. # Fraud Validation Rules GPP invokes Fraud Validation rules to determine whether to invoke the Fraud Interface for specific transactions. If a transaction meets the conditions of a defined rule, GPP uses the value defined in the Send Payment to field to determine whether to invoke the interface. The field can contain one of the following values: - BYPASS: Usually used for incoming On-Us transactions. If a transaction meets the conditions of a rule defined with this value, GPP does not invoke the Fraud Interface for the transaction and continues with the generic transaction processing workflow. - FRAUD1: Usually used for outgoing transactions. If a transaction meets the conditions of a rule defined with this value, GPP invokes the Fraud Interface for the transaction. For more information about business rules, see the GPP Online Help. # 9.2.4.2 System Configuration GPP uses system reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining system reference data, GPP can tailor system behavior to specific financial institution requirements. --- Note: GPP supplies a full set of system reference data that are customized to specific financial institution requirements. In most cases, authorized GPP users can view, but not update, system reference data. The Fraud Interface requires no specific system parameters, rules, or profiles. # 9.2.5 Message Data The Fraud Interface requires no specific message attributes. # 9.2.5.1 Audit Trail Entries GPP generates an Audit Trail entry for when invoking Fraud Interface functionality. The following table describes the Audit Trail entries that GPP might generate during anti-fraud validation. | Audit Trail Code | Description | | ---------------- | --------------------------------------------- | | 292 | Transaction was forced out of Fraud scan hold | | 293 | Transaction passed Fraud scan | | 294 | Hold received from Fraud scan | | 295 | Transaction failed Fraud scan | | | Technical Error received from Fraud scan | # 9.2.5.2 Error Codes The following table describes the error codes that GPP might generate during anti-fraud validation. | Error Code | Description | | ---------- | ----------------------------------- | | 294 | Transaction failed fraud scan. | | 943 | No Fraud validation rule is defined | Note: If a failure response contains multiple errors, GPP generates an error log entry for each error. # 9.3 Fraud Service Provider Interface (SPI) for Single Payments For details refer GPP Business Guide Application Programming Interface. # 9.3.1 Processing GPP invokes the Fraud Interface at specific exit points during the transaction processing workflow. For Service Provider Interface this will be the second point in the flow (pre-posting), relevant for outward payments. A financial institution can determine which transactions require fraud validation by defining business rules to bypass or invoke the Fraud Interface for specific transaction types. For more information, see Rules. --- # 9.3.1.1 Workflow # Fraud Validation Rule | Wait Fraud sts = | ~~Invoke Interface~~ | Action | ~~Bypass Interface~~ | Fraud Sts = B | W | | ----------------------- | -------------------- | ------------- | -------------------- | ------------------- | ---- | | Fraudex Technical Error | Response | ~~Pass~~ | Fraud sts = P | Continue Processing | Hold | | Fraud possible hit | Manual Handling | Fraud sts = H | | | | # 9.3.1.2 Details As part of the generic transaction processing workflow, GPP invokes the Fraud Interface during individual transaction processing after the Message Duplicate Check flow and before invoking the Account Lookup Interface (see Account Lookup Interface). GPP invokes this interface also at the end of the flow before posting (pre-posting). For SPI, currently the supported scope is outgoing messages therefore, only the second point (pre-posting) is used. GPP determines whether to invoke the interface using the Fraud Validation business rules. If a transaction meets the conditions of a defined rule, GPP uses the value defined in the Send Payment to field to determine whether to invoke the interface. The field can contain one of the following values: - BYPASS: If a transaction meets the conditions of a rule defined with this value, GPP does not invoke the Fraud SPI for the transaction and does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to B - Routes the transaction to the generic transaction processing workflow for continued processing - FRAUD1: If a transaction meets the conditions of a rule defined with this value, GPP invokes the Fraud SPI for the transaction. If GPP determines to invoke the Fraud SPI for a transaction, GPP does the following: - Generates an outgoing interface request in the required format (JSON) - Transmits the request to the Fraud SPI via FFDC. - Sets the transaction with a WAIT_FRAUD status and routes it to the Wait Fraud queue Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 72 --- # 9.3.1 GPP Response Handling GPP holds the transaction in the Wait Fraud queue pending receipt of a corresponding response from the Fraud SPI. Currently, only one level of response is supported via the SPI. The response is received currently in the Fndt message format as mentioned in the GPP Technical Guide - Fndt Message Usage for Fraud Interface. GPP can receive and process the following response types: - PASS: The response contains a Return Code of 1, which indicates the transaction successfully passed the fraud validations. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to P - Generates a Transaction passed Fraud scan Audit Trail entry for the transaction - Routes the transaction to the generic transaction processing workflow for continued processing - HOLD: The response contains a Return Code of 2, which indicates the possibility of fraud. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to H - Generates a Hold received Fraud scan Audit Trail entry for the transaction - Moves transactions to FRAUD_POSSIBLE_HIT status for an authorized user to manually investigate with the service provider and take manual action on the payment. - TECHNICAL FAILURE: The response contains a Return Code of 995, which indicates that fraud validations were not performed. For SPI, this can happen in case of swagger format validations or any HTTP error received from the third-party such as 400 (Bad Request) or 500 (Internal Server Error). GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to E - Generates a Technical Error received from Fraud scan Audit Trail entry for the transaction - Retains the transaction in the FRAUDEX queue # 9.3.2 Manual Handling In various transaction processing scenarios, GPP might route a transaction to a manual handling queue after invoking the Fraud Interface. Authorized GPP users can access individual transactions in these queues to determine additional transaction processing. # 9.3.2.1 Inactive Queues The Fraud SPI requires no specific Inactive queues. # 9.3.2.2 Manual Queues GPP routes transactions that are pending manual action from an authorized user to manual queues. An authorized GPP user can access individual transactions in these queues to perform manual actions. # 9.3.2.2.1 Fraud Possible Hit queue When a ‘Hold’ response is received from the Fraud SPI, GPP routes the transaction to FRAUD_POSSIBLE_HIT queue for manual handling. An authorized user accesses individual transaction in this queue and can click one of the following: - ForceFraud: Click Force Fraud to indicate that the transaction has successfully passed the manual fraud investigation with the service provider and instruct GPP to continue processing the transaction. GPP also sets the MU_FRAUD_FORCE_STATUS to A and generates an Audit Trail entry to indicate the GPP user who initiated the action. In addition, the MF_FRAUD_VALIDATION_STS set to F. --- # 9.3.2.2.1 Cancel Clicking Cancel instructs GPP to cancel the transaction, and depending on specific workflow definitions, does one of the following: - Sets the transaction with a CANCELLED status and routes it to the Cancelled queue. - Sets the transaction with an APPROVE_CANCEL queue and routes it to the Approve Cancel queue for additional manual handling. The cancel action must be approved by another authorized GPP user or the same user who initiated the action, as per workflow definitions. GPP also sets the MU_FRAUD_FORCE_STATUS to C and enables the GPP user to select either the CUST error code or the TX FRAUD error code. # Send to Repair Instructs GPP to set the transaction status to REPAIR and to route it to the Repair queue for manual handling. # Retry Instructs GPP to re-submit a single or multiple transactions at once for processing. A request is generated for each payment, and the payment waits for the response in the same (Wait Fraud) queue. # 9.3.2.2.2 Fraud Exception queue When a technical error is received from the Fraud SPI, GPP routes the transaction to FRAUDEX queue for manual handling. An authorized user accesses individual transaction in this queue and can click one of the following: # ForceFraud Click ForceFraud to indicate that the transaction has successfully passed the manual fraud investigation with the service provider and instruct GPP to continue processing the transaction. GPP also sets the MU_FRAUD_FORCE_STATUS to A and generates an Audit Trail entry to indicate the GPP user who initiated the action. In addition, the MF_FRAUD_VALIDATION_STS set to F. # Cancel Clicking Cancel instructs GPP to cancel the transaction, and depending on specific workflow definitions, does one of the following: - Sets the transaction with a CANCELLED status and routes it to the Cancelled queue. - Sets the transaction with an APPROVE_CANCEL queue and routes it to the Approve Cancel queue for additional manual handling. The cancel action must be approved by another authorized GPP user or the same user who initiated the action, as per workflow definitions. GPP also sets the MU_FRAUD_FORCE_STATUS to C and enables the GPP user to select either the CUST error code or the TX FRAUD error code. # Retry Instructs GPP to re-submit a single or multiple transactions at once for processing. A request is generated for each payment, and the payment waits for the response in the same (Wait Fraud) queue. # 9.3.2.3 Wait Queues GPP routes transactions that are waiting for a response from an external interface or system in Wait queues. An authorized GPP user can access individual transactions in these queues to perform manual actions. # 9.3.2.3.1 Wait Fraud (WAIT_FRAUD) Queue After invoking the Fraud SPI, GPP routes a transaction to the Wait Fraud queue pending a corresponding response. An authorized user accesses individual transactions in this queue and can click one of the following: # Return For incoming messages only, clicking Return invokes transaction generation of a return message. Sets the monitors (Cancel), the message goes to the WAITRETURN status until the return reaches complete, then the status changes to returned. --- • Cancel: Clicking Cancel instructs GPP to cancel the transaction, and depending on specific workflow definitions, does one of the following: - Sets the transaction with a CANCELLED status and routes it to the Cancelled queue. - Sets the transaction with an APPROVE_CANCEL queue and routes it to the Approve Cancel queue for additional manual handling. The cancel action must be approved by another authorized GPP user or the same user who initiated the action, as per workflow definitions. GPP also sets the MU_FRAUD_FORCE_STATUS to C and enables the GPP user to select either the CUST error code or the TX FRAUD error code. • Force: For transactions with a WAIT_FRAUD status only, clicking Force indicates that the transaction has successfully passed the fraud validation and instructs GPP to continue processing the transaction. GPP also sets the MU_FRAUD_FORCE_STATUS to A and generates an Audit Trail entry to indicate the GPP user who initiated the action. In addition, the MF_FRAUD_VALIDATION_STS set to F. • Retry: Instructs GPP to re-submit a single or multiple transactions at once for processing. A request is generated for each payment, and payment waits for the response in the same (Wait Fraud) queue. When processing a transaction, if the Fraud Interface is offline, GPP sets the transaction with a FRAUD_STOP status and routes it to the Wait Fraud queue. A GPP user can access the transaction when the interface comes online and click Resend to return the transaction to the transaction processing workflow, which includes a request to the Fraud Interface, for continued processing. Note: GPP users can resend a request via the GPP Processing Communication page, which they can access from the Transaction Data page. For more information, see the GPP Online Help. # 9.3.3 Business Setup and System Configuration GPP uses business setup and system configuration reference data to enable system operation, transaction processing, and UI functionality. # 9.3.3.1 Business Setup GPP uses business reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining business rules, a financial institution can tailor system behavior to specific business requirements. # 9.3.3.1.1 System Parameters FRAUD_CHECK - this system parameter indicates if the Fraud Check is part of the Single Transactions flow. When this system parameter is set to Yes, then the Fraud validation rule is invoked. # 9.3.3.1.2 Profiles The Fraud Interface requires no specific GPP profiles. # 9.3.3.1.3 Rules At various points during the transaction processing workflow, GPP invokes business rules to determine continued transaction processing and handling. # Fraud Validation Rules GPP invokes Fraud Validation rules to determine whether to invoke the Fraud Interface for specific transactions. --- If a transaction meets the conditions of a defined rule, GPP uses the value defined in the Send Payment to field to determine whether to invoke the interface. The field can contain one of the following values: - BYPASS: Usually used for incoming On-Us transactions. If a transaction meets the conditions of a rule defined with this value, GPP does not invoke the Fraud Interface for the transaction and continues with the generic transaction processing workflow. - FRAUD1: Usually used for outgoing transactions. If a transaction meets the conditions of a rule defined with this value, GPP invokes the Fraud Interface for the transaction. For more information about business rules, see the GPP Online Help. # 9.3.3.2 System Configuration # 9.3.3.2.1 Profiles The Fraud SPI requires one designated interface for sending the requests to and one for receiving responses. # 9.3.3.2.2 Rules GPP uses system reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining system reference data, GPP can tailor system behavior to specific financial institution requirements. Note: GPP supplies a full set of system reference data that are customized to specific financial institution requirements. In most cases, authorized GPP users can view, but not update, system reference data. The Service Provider Interface (SPI) for Fraud, requires a specific Interface Selection (rule 189) rule named “FRAUD_OUT_SPI”. This rule is attached as default as last in sequence. In order to enable its usage, this rule needs to be the first rule attached. The Fraud SPI functionality is also applicable for Immediate Payment. # 9.4 Fraud Interface for Immediate Payment # 9.4.1 Processing GPP invokes the Fraud Interface at specific exit points during the transaction processing workflow. A financial institution can determine which transactions require fraud validation by defining business rules to bypass or invoke the Fraud Interface for specific transaction types. For more information, see Rules. # 9.4.1.1 Workflow The following shows the Fraud Interface workflow. Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 76 --- Fraud validation rule # 9.4.1.2 Details As part of the generic transaction processing workflow, GPP invokes the Fraud Interface during individual transaction processing after the Message Duplicate Check flow and before invoking the Account Lookup Interface (see Account Lookup Interface). GPP determines whether to invoke the interface using the Fraud Validation business rules. If a transaction meets the conditions of a defined rule, GPP uses the value defined in the Send Payment to field to determine whether to invoke the interface. The field can contain one of the following values: - BYPASS: Usually used for incoming or On-Us transactions. If a transaction meets the conditions of a rule defined with this value, GPP does not invoke the Fraud Interface for the transaction and does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to B - Routes the transaction to the generic transaction processing workflow for continued processing - FRAUD1: Usually used for outgoing transactions. If a transaction meets the conditions of a rule defined with this value, GPP invokes the Fraud Interface for the transaction. If GPP determines to invoke the Fraud Interface for a transaction, GPP does the following: - Generates an outgoing interface request in the required format - Transmits the request to the financial institution's external fraud interface - Sets the transaction with a WAIT_FRAUD status and routes it to the Wait Fraud queue Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 77 --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide If a transaction does not meet the conditions of a defined Fraud Validation business rule, GPP cancels the transaction by doing the following: - Generates a 943 error code for the transaction (see Error Codes) - Sets the transaction with a CANCELLED status - Routes the transaction to the Cancelled queue, which is a final status GPP holds the transaction in the Wait Fraud queue pending receipt of a corresponding response from the financial institution’s interface. GPP can receive and process the following response types: # PASS The response contains a Return Code of 1, which indicates the transaction successfully passed the financial institution’s fraud validations. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to N - Generates a Transaction passed Fraud scan Audit Trail entry for the transaction - Routes the transaction to the generic transaction processing workflow for continued processing # HOLD The response contains a Return Code of 2, which indicates the pending arrival of an additional response from the external interface. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to W - Generates a Hold received Fraud scan Audit Trail entry for the transaction - Holds the transaction in the Wait Fraud queue until receipt of the second response, which can be either a PASS or FAIL, as previously described. # FAIL The response contains a Return Code of 0, which indicates the transaction did not pass the financial institution’s fraud validations. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to H - Generates a Transaction failed Fraud scan Audit Trail entry for the transaction - Sets the transaction status to FRAUDEX Note: A financial institution can define specific business rules that GPP uses to notify the initiating party of a failed fraud validation. If a transaction meets the conditions of a defined rule, GPP generates and transmits a Notification message that contains a reason for the failure. For more information about business rules, see the GPP Online Help. # TECHNICAL FAILURE The response contains a Return Code of 995, which indicates that GPP did not perform the financial institution’s fraud validations. GPP does the following: - Sets the MF_FRAUD_VALIDATION_STS monitor field to E - Generates a Technical Error received from Fraud scan Audit Trail entry for the transaction - Sets the transaction status to FRAUDEX Until receipt of a corresponding response from the external interface, an authorized GPP user can access individual transactions in the Wait Fraud queue to perform a manual action, which GPP uses to determine continued transaction processing. For more information, see Wait Fraud (WAIT_FRAUD/FRAUD_STOP) Queue. GPP also supports the following exceptions: - Interface Offline: If the Fraud Interface is offline, GPP sets the transaction with a FRAUD_STOP status, which requires manual handling. - Technical Issue: If GPP is not able to invoke the Fraud Interface because of a technical issue, an authorized GPP user can resend or cancel the transaction. Page 78 --- • Timeout: If GPP does not receive a corresponding response within a specified amount of time, GPP routes the transaction to the cancellation flow. For more information about manual handling, see Manual Handling. All transaction updates from the Fraud Interface generate relevant Audit Trail entries. For more information, see Audit Trail Entries. Note: If a failure response contains multiple errors, GPP generates an error log entry for each error. # 9.4.2 Response/Request Matching In general, on Request/Response interfaces GPP supports matching methods (some functional and some technical) between the request, sent from GPP, and the response, received from the external financial institution system. - The functional, and more generic, method is the usage of <ContecName> and <contexLocalName>, quoting, in the response, their value/s from the request + the P_MID. - There are additional technical methods that allow echo back of the sending system (for example, GPP or a HOST channel) identifier in a custom property of the MQ header (the value of this identifier is captured from the request as transport property) or using the MQ correlation ID in the MQ envelope. Note: The Event ID is not currently used in the matching, therefore it is not mandatory to be returned in the response. # 9.4.3 Manual Handling In various transaction processing scenarios, GPP might route a transaction to a manual handling queue after invoking the Fraud Interface. Authorized GPP users can access individual transactions in these queues to determine additional transaction processing. # 9.4.3.1 Inactive Queues The Fraud Interface requires no specific Inactive queues. # 9.4.3.2 Manual Queues The Fraud Interface requires no specific Manual queues. # 9.4.3.3 Wait Queues GPP routes transactions that are waiting for a response from an external interface or system in Wait queues. An authorized GPP user can access individual transactions in these queues to perform manual actions. # 9.4.3.3.1 Wait Fraud (WAIT_FRAUD/FRAUD_STOP) Queue After invoking the Fraud Interface, GPP routes a transaction to the Wait Fraud queue pending a corresponding interface response. An authorized user accesses individual transactions in this queue and can click one of the following: - Cancel: Clicking Cancel instructs GPP to cancel the transaction, and depending on specific workflow definitions, does one of the following: GPP also sets the MU_FRAUD_FORCE_STATUS to C and enables the GPP user to select either the CUST error code or the TX FRAUD error code. --- • Force: For transactions with a WAIT_FRAUD status only, clicking Force indicates that the transaction has successfully passed the fraud validation and instructs GPP to continue processing the transaction. GPP also sets the MU_FRAUD_FORCE_STATUS to A and generates an Audit Trail entry (see Audit Trail Entries) to indicate the GPP user who initiated the action. When processing a transaction, if the Fraud Interface is offline, GPP sets the transaction with a FRAUD_STOP status and routes it to the Wait Fraud queue. A GPP user can access the transaction when the interface comes online and click Resend to return the transaction to the transaction processing workflow, which includes a request to the Fraud Interface, for continued processing. Note: GPP users can resend a request via the GPP Processing Communication page, which they can access from the Transaction Data page. For more information, see the GPP Online Help. # 9.4.4 Business Setup and System Configuration GPP uses business setup and system configuration reference data to enable system operation, transaction processing, and UI functionality. # 9.4.4.1 Business Setup GPP uses business reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining business rules, a financial institution can tailor system behavior to specific business requirements. # 9.4.4.1.1 System Parameters The Fraud Interface requires no specific system parameters. # 9.4.4.1.2 Profiles The Fraud Interface requires no specific GPP profiles. # 9.4.4.1.3 Rules At various points during the transaction processing workflow, GPP invokes business rules to determine continued transaction processing and handling. # Fraud Validation Rules GPP invokes Fraud Validation rules to determine whether to invoke the Fraud Interface for specific transactions. If a transaction meets the conditions of a defined rule, GPP uses the value defined in the Send Payment to field to determine whether to invoke the interface. The field can contain one of the following values: - • BYPASS: Usually used for incoming On-Us transactions. If a transaction meets the conditions of a rule defined with this value, GPP does not invoke the Fraud Interface for the transaction and continues with the generic transaction processing workflow. - • FRAUD1: Usually used for outgoing transactions. If a transaction meets the conditions of a rule defined with this value, GPP invokes the Fraud Interface for the transaction. For more information about business rules, see the GPP Online Help. # 9.4.4.2 System Configuration GPP uses system reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining system reference data, GPP can tailor system behavior to specific financial institution requirements. --- Note: GPP supplies a full set of system reference data that are customized to specific financial institution requirements. In most cases, authorized GPP users can view, but not update, system reference data. The Fraud Interface requires no specific system parameters, rules, or profiles. # 9.4.5 Message Data The Fraud Interface requires no specific message attributes. # 9.4.5.1 Audit Trail Entries GPP generates an Audit Trail entry for when invoking Fraud Interface functionality. The following table describes the Audit Trail entries that GPP might generate during anti-fraud validation. | Audit Trail Code | Description | | ---------------- | --------------------------------------------- | | 292 | Transaction was forced out of Fraud scan hold | | 293 | Transaction passed Fraud scan | | 294 | Hold received from Fraud scan | | 295 | Transaction failed Fraud scan | | | Technical Error received from Fraud scan | # 9.4.5.2 Error Codes The following table describes the error codes that GPP might generate during anti-fraud validation. | Error Code | Description | | ---------- | ----------------------------------- | | 294 | Transaction failed fraud scan. | | 943 | No Fraud validation rule is defined | Note: If a failure response contains multiple errors, GPP generates an error log entry for each error. # 10 Online Foreign Exchange Interface # 10.1 Overview The GPP Currency Conversion mechanism handles the conversion between two currencies using either a quoted rate or a cross currency conversion rate. GPP obtains foreign exchange (FX) rates for currency conversion from either of the following: - Internal Mechanism: GPP accesses an internal mechanism to obtain FX rates. For more information, see the GPP Currency Conversion Business Guide. - External Standard Interface: GPP invokes an external interface to retrieve FX rates. Note: GPP invokes an external standard FX interface only when processing inward or outward credit transfers. - External Interface with FX Provider: GPP invokes an external interface to retrieve FX rates from another bank. --- # 10.2 Processing # 10.2.1 Workflow FX Payment | SWIFT/Clearing/ | GPP | Accounting | External FX | | --------------- | ---------- | ----------------------------------------- | ----------- | | CREATE | Payment | Account Lookup, CustomerData | | | Payment | Processing | Continue Processing using Indicative Rate | | -No Processing Date? | | SCHE DULED | queue | | ------------------ | ---------- | ----- | | Contract received? | Yes | No | Above Threshold? | Yes | No | | --- | -- | FXWAITQ Request: VALLOCK/RSSTP Customer Contracts, Rates Response Type —Response: Positive/Negative Positive Negative FX Positive Responses FXREPAIR Contract validated Rate auto-booked under threshold for Non-Dealing and predefined Dealing # FX Tab Options - Get Deals - User Action Initial Requests: GETDEALS/GETRATE - Get Rate Initial Responses: Deals/Quote - Accept/Reject Quote - Lock Deal (Submit) Submit Accept/Reject Secondary Request: ACCLOCK/REJRATE Negative Response 1 ACCLOCK Customer FXWAITQ PositiveType Request: VALLOCK Negative REJRATE: Positive/Negative Response Type VALLOCK/2 ACCLOCK: Positive/Negative Positive FX Responses VALLOCK upon Submit for contract 2 ACCLOCK upon Accept for rate --- # 10.2.2 Details As part of the generic transaction processing workflow, GPP invokes the Online FX interface during individual transaction processing after the debit/credit side derivation flow and before the posting flow. Note: GPP does not support currency conversion on both the debit and credit side for a single transaction. If a transaction requires both debit and credit currency conversion, GPP routes the transaction to a manual queue, such as FX Repair, for manual handling. The interface does the following: - Evaluates the Rate usage selection rules, applying the relevant Rate usage profile. The Rate Usage profile is configured with the external interface name. - Applies an indicative rate as the standard rate, which is later overridden by the external received rate. - Initiates a request to the external FX engine: - If a contract is included in the transaction and regardless if the transaction exceeds a defined threshold, GPP generates a Validate and Lock (VALLOCK) request, and routes the transaction to FX Wait queue. - If no contract is included in the transaction and the transaction amount is below a defined threshold, GPP generates a Rate Request STP (RRSTP) request, and routes the transaction to FX Wait queue. - If no contract is included in the transaction and the transaction amount exceeds a defined threshold, the transaction is routed to a manual queue as configured in the Rate usage profile’s field Above threshold to go (for example, FX Rate Repair queue, Repair queue). - Receives and matches a response from the FX interface: - Positive response for a validated contact: The transaction continues to be processed. - Negative (error) response: The transaction is routed to FX Rate Repair queue for user intervention. In case technical error is received (return code 990) the payment status is either set to FX_STOP and is routed to the Inactive queue or proceeds with the payment processing, depending on the inactivity behavior configured on the interface. FX interface can be configured to deactivate on the receipt of the first technical error response. The default behavior – technical error response does not deactivate the interface. - Invokes a retry mechanism to invoke the external interface if the response is not received within a configurable timeout period. GPP invokes the interface a configured number of times, after which the interface becomes inactive and Online FX request is treated as failed. For more information about interface timeout, see the GPP Interfaces Technical Guide. # 10.3 Manual Handling In various transaction processing scenarios, GPP might route a transaction to a manual handling queue after invoking the Online FX interface. Authorized GPP users can access individual transactions in these queues to determine additional transaction processing. # 10.3.1 Manual FX Updates An authorized user can manually update FX information for a transaction via the transaction’s FX tab in the GPP User Interface. A user can do the one of the following: - Add FX Information: A user can specify a single Customer Contract ID and its respective rate. When the user submits the transaction for processing, GPP generates a VALLOCK request and transmits it to the external FX interface. --- • Not Add FX Information: A user can leave the FX information empty. When the user submits the transaction for processing, GPP generates a Rate Request STP (RRSTP) request and transmits it to the external FX interface. Based on the response received from the FX engine, the transaction continues with the process or is routed to FX Repair Queue (see FX Repair Queue). # 10.3.2 Wait Queues # 10.3.2.1 FX Wait Queue After invoking the Online FX interface, GPP routes a transaction to the FX Wait queue pending a corresponding interface response. An authorized user accesses individual transactions in this queue and can click one of the following: - Send to FX Repair: Instructs GPP to send a single transaction or group of transactions to the FX Repair (FXREPAIR) queue for manual update. GPP sets the transaction status to FXREPAIR and routes it to the FX Repair queue. - Processing Communications: Opens the Processing Communications page to enable the user to resend the interface request. GPP uses the same event ID (if exists). - Cancel: Instructs GPP to cancel a single transaction or transactions in bulk. GPP routes the transaction(s) to the cancellation flow, including earmark release and/or reverse posting, if either are required. - Retry: Instructs GPP to re-submit a single or multiple transactions at once for processing. A request is generated for each payment, and the payment waits for the response in the same (FX Wait) queue. # 10.3.2.2 Wait Payment Info Queue Note: This queue is only relevant when the LOWER_TIER_ENABLED system parameter is set to Yes. The queue includes the messages that have already received a positive response from the FX provider. The payments in this queue are waiting for the Payment Information response from the provider. Once a positive response from the Payment Information interface is received the payment continues to the posting step of the Single Payment processing flow. # 10.3.3 Inactive Queue When the relevant interface is not active or a technical negative response is received (return code 990), GPP behaves according to the inactive behaviour set for this interface, as per the generic interfaces functionality (for more details see GPP Interfaces Technical Guide). For the interfaces that are configured with Non-active behavior of STOP_UNTIL_ACTIVE or PERMANENT_STOP, the transaction waits in the inactive queues, for the relevant interface to become active. # FX STOP Queue (FXSTOP) If the FX interface Non-active behavior is setup as STOP_UNTIL_ACTIVE or PERMANENT_STOP, when the interface goes down or technical error response is received (return code 990), the transaction is visible to the user in the FX Stop queue (FXSTOP). In this queue users can perform Cancel and Send to Repair actions. # GPP Processing: - Cancel: The transaction is routed to cancellation flow, including earmark release (for example, if the Account Lookup cannot be performed on the target credit account, while Balance Inquiry on the debit account already took place), or reverse posting, whenever required (for example, if the --- # 10.3.4 Manual Queues # 10.3.4.1 FX Repair Queue After invoking the Online FX interface, GPP routes a transaction to the FX Repair queue to enable FX information updates. An authorized user accesses individual transactions in this queue and can click one of the following: - Submit: After manual updates, instructs GPP to submit the transaction for continued processing. For example, a user can add a Contract ID, after which, GPP generates a Validate and Lock (VALLOCK) request and routes the transaction to FX Wait Queue (same as when the contract is included in original payment). - Get Deals: After defining a relevant contract, instructs GPP to submit the transaction for continued processing. GPP does the following: - GPP sends a GETDEAL request (synchronic) to an external FX engine. - A positive response from the FX engine returns all valid contracts for the relevant currency pair and amount. - Note: A negative response displays the relevant error transaction. - GPP stores the contract information (contract reference, amount) and displays it on the transaction’s FX tab (MessageRates table). - A single contract needs to be displayed on the FX tab. All irrelevant contracts need to be deleted by selecting the contract, clicking Delete, and then Recalculate to save the changes made to the grid. - The user clicks Submit and GPP sends a Validate and Lock (VALLOCK) request to the external FX interface and routes the transaction to FX Wait Queue. - Note: If required, all the contracts can be deleted from the FX tab, and a dealer rate can be requested from the FX engine by clicking Get Rate. - Get Rate: Instructs GPP to request a dealer rate for the relevant currency and pair amount. GPP does the following: - Generates a GETRATE request (synchronic), and routes the transaction to FX Wait Queue. - In the response from the external FX engine, a respective Dealer Rate is auto-populated on the FX tab and a dialogue box appears displaying the rate and a countdown timer. The user has two options: - Approve: Accepts the quote, sends an Accept and Lock (ACCLOCK) request, and routes the transaction to FX Wait queue to wait for a response from the external FX engine. - Note: If a positive response is received, GPP continues to process the transaction. If a negative response is received, the transaction is routed back to FX Repair queue. - Reject: Rejects the quote, closes the dialogue box, sends a Reject Rate (REJRATE) response and clears the received rate from the FX tab table, allowing the user to continue to process the transaction. - Note: If a negative response is received, a relevant error message is generated. - Note: If the quote expires (the countdown timer on the dialogue box reaches 0 seconds), the quote expires and both Approve and Reject buttons are disabled. - Cancel: Instructs GPP to cancel the transaction. GPP routes the transaction to the cancellation flow, including earmark release and/or reverse posting, if either are required. --- # 10.3.4.2 FX Rate Repair Queue for Lower Tier FIs After invoking the Online FX interface, GPP routes a transaction to the FX Repair queue to enable FX information updates. An authorized user accesses individual transactions in this queue and can click one of the following: - Get Rate: Instructs GPP to request a dealer rate for the relevant currency and pair amount. When this is selected GPP does the following: - Generates a GETRATE request (asynchronic). - In the response from the external FX engine, a respective Dealer Rate is auto-populated on the FX tab and a dialogue box appears displaying the rate and a countdown timer. The user has two options: - Approve: Accepts the quote, sends an Accept and Lock (ACCLOCK) request, and waits for a response from the external FX engine. Note: If a positive response is received, the payment stays in the FX Rate Repair and the user can submit for further processing. The payment is then sent to the Wait Payment Info queue. If a negative response is received, the transaction is routed back to FX Repair queue. - Reject: Rejects the quote, closes the dialog box, and clears the received rate from the FX tab table, allowing the user to continue to process the transaction. Note: If a negative response is received, a relevant error message is generated. - Note: If the quote expires (the countdown timer on the dialog box reaches 0 seconds), the quote expires and both Approve and Reject buttons are disabled. - Before posting, the Payment Information interface is triggered to the provider and the payment is sent to the Wait_PMT_INFO queue, until a positive response is received. The request message is sent to the provider in the full FndtMsg format. - When a negative response is received from Payment Information interface the payment is routed to Repair where the user can update the payment (Debit amount, currency, and account are disabled and the FX tab is disabled). The user can resubmit the payment and Payment Information interface is triggered and the payment is routed to the Wait_PMT_INFO queue. - Cancel: Instructs GPP to cancel the transaction. GPP routes the transaction to the cancellation flow, including earmark release and/or reverse posting, if either are required. --- # 10.3.4.2.1 Workflow End To end flow Get FX Rate from FX provider | GPP USER | GPP | GFX | Fx Provider | Clearing Gateway(FED) | | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | ------------------------- | --------------------- | | Message | Verity | Create | Account | conversion lookup | | Submit | Belence | Trigger debit FX conversion flow | FX RATE | \_Payment amount, | | Eveluate rate usage | Payment amount | BAU STP flow | REPAIR | above threshold | | Get Rate | | Provider's FX system | | | | Exception flow1 | No | Positive response received | yes | | | Display Rate in message rates window with Accept button and start timer countdown | | | | | | Exception flow2 | No | Accept performed on time | -γes- | | | Accept | Accept Button becomes disabled | | | | | Exception flow3 | -No | | Accept rate | Response | | yes | Display Rate with debit amount and deal reference with Popup notification to user, Dealer reference received, deal is booked | APPROVE\_REG | | | | Continue with | Compliance | BAU HV Flow | Froud | | | System option | No | BAU flow | Low tier Bank | | | Send payment information to provider quoting the settlement and debit amount | Payment info to Provider interface in Fundt | Send Payment Information | Provider's payment system | | | wait\_PM | T\_INFO | | | | | Exception flow4 | Positive response received | -Get Payment acknowledgement | | | | Exceptio | Debit leg Posting | n flow3 | oI | | | Complete | | | | | | Consolidat | Provider defined No. | in Itemized mode | flow | | | Generate single | FED transaction | WAIT\_ACK | Message SENT | (itemized Mode) | | Exception | lok | Cresit leg 0k→ Complete | Fed Acknowledgement | Received | # 10.3.4.3 Rate Received from External Interface During Create During message create, users are able to get the conversion rate from the synchronous Online FX interface. Users must enter the mandatory fields required for debit currency conversion (debit currency, settlement currency, debit account, and debit amount / settlement amount). User must select the FX tab and select the following: Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 87 --- • Get Rate: Instructs GPP to request a dealer rate for the relevant currency and pair amount. When this is selected GPP does the following: - Generates a GETRATE request (synchronous). - In the response from the external FX engine, a respective dealer rate is auto-populated on the FX tab and a dialog is displayed with the rate and a countdown timer. The user has two options: - - Approve: Accepts the quote, sends an Accept and Lock (ACCLOCK) request, and waits for a response from the external FX engine. Note: If a positive response is received, the payment stays in Create and the user can submit for further processing. If a negative response is received, the transaction will remain in Create and user is able to perform Get Rate again. - Reject: Rejects the quote, closes the dialog box, and clears the received rate from the FX tab table, allowing the user to perform Get Rate again, or continue to process the transaction. Note: If a negative response is received, a relevant error message is generated. Note: If the dealer rate expires (the countdown timer on the dialog box reaches 0 seconds), the rate expires and both the Approve and Reject buttons are disabled. # 10.4 Business Setup and System Configuration # 10.4.1 Business Setup # 10.4.1.1 Business Rules Rate Usage for Credit Side Conversion, Rate Usage for Debit Side Conversion and Rate Usage for Base Conversion should be setup to determine the external FX Rate usage. The rules should be set up to meet a financial institution’s business requirements. # 10.4.1.2 Profiles # 10.4.1.2.1 Rate Usage Profile For an external FX call, the Rate Usage profile should be defined with a Standard rate sheet and the relevant interface name under Rate interface name fields. In addition, the threshold for direct conversion may be defined, along with the relevant manual queue in the Above Threshold Go To field. # 10.4.1.3 System Parameters The following table describes the business related system parameters that enable Online FX interface functionality. | Name | Description | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | FX\_THRESHOLD\_AFTER\_SCHEDULE | Determines whether GPP evaluates the FX threshold defined in a Rate Usage profile on the actual processing date of the transaction (after schedule). | | | • Y: GPP evaluates the FX threshold on the transaction's processing date. | | | • N: GPP evaluates the FX threshold when the Rate Usage profile associated with the transaction is evaluated. | | LOWER\_TIER\_ENABLED | Indicates if lower tier bank offering is enabled. Yes or No. | --- # 10.4.2 System Configuration # 10.4.2.1 Profiles The Online FX interface requires no specific system profiles. # 10.4.2.2 Rules # 10.4.2.2.1 Interface Selection Rule Interface Selection rules can be configured to meet a financial institution’s requirements to select the relevant Online FX interface, specifically when multiple interfaces are used. - An asynchronous interface is selected based on the Rate Usage profile. - A synchronous interface is selected based on user’s manual action (Get Rate or Get Deals). # 10.4.2.3 System Parameters The Online FX interface requires no specific system parameters. # 10.5 Message Data The Online FX interface requires no specific Message Attributes, error messages, or Audit Trail entries. # 11 Posting Interface For information on the business functionality and business setup for the posting logic and interface, see the GPP Posting Business Guide. # 12 Billing Events Interface # 12.1 Overview GPP can be configured to generate Billing Notifications for specific types of events that can occur during the High Value Single Payment and Mass Payment SEPA message processing workflows. GPP generates these billing notifications according to specific conditions and sends them to MQ for retrieval by the financial institution, which can then be extracted for use in their own external reporting and billing systems. GPP generates a transaction-level Billing Notification for the following workflow events: - High Value - Single Payments - Accounting Messages: - Message in Complete, Rejected, Returned, Canceled, Seized - The message has a fee applied with MSG_FEES.APPLY='LATER' - Mass Payment - SEPA Payments: - Accounting Messages: - S Message in COMPLETE, CANCELED - I Message in COMPLETE, REJECTED, RETURNED, CANCELED, SEIZED - No need for A message - The message has a fee applied with MSG_FEES.APPLY='LATER' --- # 12.2 High Level Workflow FINASTRA Fusion Global PAYplus kafka Payment event Billing JMS MQ Adapter Billing System # 12.3 Business Setup # 12.3.1 System Parameters | Name | Description | | ------------------ | ------------------------------------------------ | | BLLING\_REPORTS | Specifies if billing reports should be published | | DASHBOARD\_ENABLED | Specifies if Dashboard is enabled | # 12.3.2 Billing Event Interfacing Profile This profile gives users the ability to pre-configure the required attributes to be used for different implementation solutions for connectivity with the billing system. # 12.3.3 Interfaces | Name | Type | Sub Type | | -------------- | ---- | -------- | | DATA\_PAYMENTS | DATA | PAYMENT | | DATA\_FILES | DATA | FILE | | DATA\_BATCHES | DATA | BATCH | --- Appendix A: Manual Actions per Queues Only the manual actions which have a GPP process for the Interfaces are described in this appendix. For all other actions, see GPP Online help. A single transaction may be stopped in relation to interfaces in these queue types. Note: The actions are always available (subject to specific user permissions) unless stated otherwise in the Description column. | Interface Type | Queue | Action | Description | | --------------- | -------------------------- | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account Lookup | Wait CDB Response | Cancel | Initiates the cancelation of the transaction. The transaction is routed to cancellation flow, including earmark release, when required (for example, if the Account Lookup is pending on the target credit account, while Balance Inquiry on the debit account already took place), or reverse posting, when required (for example, if the Account Lookup is on the target credit account, while Posting on the debit leg already took place). | | Balance Inquiry | Wait Balance Inq. Response | Force | GPP continues processing even though the no response was received. **Note:** Only entitled users whose user profile maximum force limit amount is greater than the message amount can use this action. | | Balance Inquiry | Wait Balance Inq. Response | Retry Bal. Inq. | GPP retries the processing of the message. The CDB monitor is kept as P, if external Account Lookup is required and was performed earlier in the flow, to allow skipping an additional invocation of the Account lookup, when message is reprocessed. When reaching the points in the flow for another request - Balance inquiry, and as the Balance Inquiry monitor is not set to P, as an indication that this step already ended successfully, GPP generates a new request to the HOST system, quoting a new Event ID. The transaction is routed to Wait Balance Inq. (BIWAITQ) pending response from HOST system. | | Balance Inquiry | Wait Balance Inq. Response | Send to Repair | GPP sends the message to the Repair queue for manual adjustments. | | Balance Inquiry | Wait Balance Inq. Response | Cancel | Initiates the cancelation of the transaction. The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required (for example, if the Balance Inquiry is pending on the second leg (target debit account), and Posting was already performed on first leg). | | Feeder | Wait Rate | It is an event and not an action | The automated WAIT\_TRIGGER\_RATE event releases the transaction for re-computation of the rate for it, in a scenario in which it is stopped. | Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 91 --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide | Interface Type | Queue | Action | Description | | --------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Posting | Wait | Release – As Positive Posting | • If configured for dual approval, the transaction is routed to the Approve Manual Posting Response queue for approval/rejection. • If not configured for dual approval, (or after approval within the above queue), GPP releases the transaction to continue processing, even though a Posting request was previously sent for it, and no response received, emulating a positive Posting response. | | Wait | Release – As Negative Posting | • If configured for dual approval, the transaction is routed to the Approve Manual Posting Response queue for approval/rejection. • If not configured for dual approval, (or after approval within the Approve Manual Posting Response queue), GPP releases the transaction to continue processing, even though a Posting request was previously sent for it, and no response received, emulating a negative Posting response. | | | Posting | Wait | Cancel | Initiates the cancelation of the transaction. The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required (for example, if Posting is pending on the second leg, and Posting was already performed on first leg). | | Account Lookup | Inactive | Cancel | The transaction is routed to cancellation flow, including earmark release, when required (for example, if the Account Lookup cannot be performed on the target credit account, while Balance Inquiry on the debit account already took place), or reverse posting, when required (for example, if the Account Lookup cannot be performed on the target credit account, while Posting on the debit leg already took place). | | Balance Inquiry | Inactive BI | Cancel | Initiates the cancelation of the transaction. The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required (for example, if the Balance Inquiry cannot be performed on the second leg (target debit account), and Posting was already performed on first leg). | | Posting | Stop | Cancel | The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required. | --- # Interface | Queue | Action | Description | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ----------- | | Feeder / Account Lookup / Balance Inquiry / Posting | Repair | Submit | | Submits the transaction for reprocessing after user amendments to the transaction details. | | | | • When reaching the point/s of Account Lookup | | | | - If the relevant CDB monitor is not set to P, to indicate a successful Account Lookup, or if the relevant account was updated by the user, an additional invocation of the Account lookup for the relevant account is triggered. | | | | • When reaching the point of Balance Check | | | | - If the BI monitor is not set to P (either it was stopped before or due to a Balance Inquiry response), the Balance Inquiry interface is triggered. | | | | - If this monitor is P, to indicate a successful Balance Inquiry, but the Posting monitor indicates failure, and if relevant transaction attributes were changed (account, amount, value date), and if working in Earmark mode, an Earmark Release request along with the new Balance Inquiry with earmark hold request are triggered, each quoting a new event ID. | | | | • When reaching the point of Posting the Posting interface is triggered. | | | | - The Posting entries are re-calculated and compared with previous entries not already marked as successful/reversed. If they are different (may happen when relevant transaction attributes (account, amount, value date) were changed), reversed posting entries are created for these non-final entries, along with the newly calculated entries. These are included in the Posting request/s and are sent, quoting a new Event ID. | | | | Note: The Account Lookup on the credit account is performed on the account of the party that is first in the credit chain (after the GPP chain enrichment). If the Credit account was entered manually, while in the Repair queue, and needs to be validated via Account Lookup, it must quote the same first in chain account, as GPP does not take it into account for the credit Account Lookup. | | | | Feeder / Account Lookup / Balance | Repair | Cancel | | Initiates the cancelation of the transaction. | | | | The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required. | | | Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 93 --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide # Interface | Queue | Action | Description | Type | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------ | ---------------- | ------------------------------------------------------------------------------ | | Balance Inquiry / Posting | Insufficient Funds | Force Ins. Funds | GPP continues processing even though the debit account has insufficient funds. | | * If routed to this queue due to Balance Inquiry response (the BI interface monitor is not P), the Balance inquiry interface generates a new request to the HOST system, quoting a new Event ID, and indicating that the user allows transaction processing to continue even though the account has insufficient funds (if using the Standard Fndt Message - MU\_NSF\_FORCE\_STS = 1 within the added Monitors extension). In Balance Inquiry with Earmark mode, the transaction is routed to Wait Balance Inq. Response (BIWAITQ) pending response from HOST system. * If routed to this queue due to Posting response (the relevant Posting interface monitor is not P), Posting interface is triggered to generate new request/s to the HOST system, quoting a new event ID and including the additional information of the user decision to force the processing even with no sufficient funds in the account, either specifically quoting the MU\_NSF\_FORCE\_STS monitor as 1, or providing a more general force indication, for all posting entries, which is relevant for both user actions of posting restriction override and force NSF (if using the Standard Fndt Message - F\_POSTING\_INFO\_FORCE\_POST\_IND=1). The transaction is routed to Wait Posting (MP\_WAIT) pending response from HOST system.Note: Only entitled users whose user profile maximum force limit amount is greater than the message amount can use this action button. | | | | | | Balance Inquiry / Posting | Insufficient Funds | Retry Ins. Funds | GPP performs the Balance Inquiry or posting interface call again. | | Transaction is submitted back to try reprocessing again, eventually triggering another invocation of Balance Inquiry or Posting (depending on the interface which failed for Insufficient Funds). Interface generates new request/s to the HOST system, quoting a new event ID. The transaction is routed to Wait Balance Inq queue or Wait Posting queue (depending on the interface type), pending response from HOST system. | | | | Page 94 --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide | Interface | Queue | Action | Description | | ------------------------------------------ | ------------------ | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Balance Inquiry / Posting | Insufficient Funds | Send to Repair | GPP sends the transaction to the Repair queue for manual adjustments. | | Balance Inquiry / Posting | Insufficient Funds | Cancel | Initiates the cancelation of the transaction. The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required. | | Account Lookup / Balance Inquiry / Posting | Restrictions | Override | GPP overrides the restriction | - MU_STOP_FLAGS_OVERRIDE_STS is set to O, to indicate that the posting restriction was overridden, and processing continues from this point in the flow. - For Account Lookup, if the relevant CDB monitor is not already P (if the failure with posting restrictions returned in an Account Lookup response), it is set to P to allow skipping an additional invocation of the Account Lookup on this account, when message is reprocessed. - For Balance Inquiry, when reaching the point of Balance Check, whether the first time or as part of the re-processing, but only if the BI monitor is not P (meaning that the transaction was routed to this queue later in the flow due to a Posting response), the Balance inquiry interface generates a request to the HOST system, quoting a new event ID and indicating that the restriction was overridden (if using the Standard Fndt Message - MU_STOP_FLAGS_OVERRIDE_STS = O). In Balance Inquiry with Earmark mode, the transaction is routed to Wait Balance Inq. Response (BIWAITQ) pending response from HOST system. - When reaching the point of Posting, whether the first time or as part of the re-processing, Posting interface generates a request to the HOST system, quoting a new Event ID and including the additional information of the user decision to override posting restrictions, either specifically quoting the MU_STOP_FLAGS_OVERRIDE_STS monitor as O, or providing a more general force indication, for all posting entries, which is relevant for both user actions of posting restriction override and force NSF (if using the Standard Fndt Message - F_POSTING_INFO_FORCE_POST_IND=1). - indicating per each posting entry that it should be forced if using the Standard Fndt Message - F_POSTING_INFO_FORCE_POST_IND=1 Page 95 --- # Interface Queue Action Description | Type | Queue | Action | Description | | ------------------------------------------ | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account Lookup / Balance Inquiry / Posting | Posting | Retry Post. Rest | GPP tries to process the transaction again. • If routed to this queue due to Account Lookup response, another attempt of the Account lookup (for the relevant side which failed previously due to posting restrictions) is performed. So, in this case, the relevant CDB monitor is cleared to simulate an initial invocation of Account Lookup. The transaction is routed to Wait CDB Response (CDBWAIT) pending response from HOST system. • If routed to this queue due to Balance Inquiry or Posting response, the relevant CDB monitor is kept as P, if external Account Lookup is required and was performed earlier in the flow, to allow skipping an additional invocation of the Account lookup, when message is reprocessed. When reaching the points in the flow of Balance inquiry or Posting, and only when the relevant monitor is not P, the relevant Interface generates new request/s to the HOST system (Posting interface uses same posting entries), quoting a new Event ID. The transaction is routed to Wait Balance Inq. (BIWAITQ) or Wait Posting (MP\_WAIT), depending on the interface type, pending response from HOST system. | | Posting | Send to Repair | Sends the message to the Repair queue for manual adjustments. | | | Posting | Cancel | Initiates the cancelation of the transaction. The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required. | | Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 96 --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide | Interface Type | Queue | Action | Description | | ----------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Posting | Exception Queue | Release – As Positive Posting | • If configured for dual approval, the transaction is routed to the Approve Manual Posting Response for approval/rejection. • If not configured for dual approval (or after approval within the Approve Manual Posting Response queue), releases the transaction to continue processing, even though a negative posting response was received (probably after manually handling in the financial institution’s accounting system), emulating an overriding positive Posting response. | | | Send to Repair | Sends the message to the Repair queue for manual adjustments. | | | | Cancel | Initiates the cancelation of the transaction, including earmark release, when required. If partial posting has been successfully performed, the successful posting entries are reversed. | | | Compliance | Wait OFAC Queue | Processing | Opens the Processing Communications page for a user to resend the interface request, quoting the same event ID (if exists). | | Wait OFAC Queue | Force | Instructs GPP to continue processing the message as if no hit was detected. | | | Wait OFAC Queue | Reject/Return | Opens a new Transaction page for users to input required data and submit. The outgoing return is processed to completion to be sent out. When return is in Complete, original transaction is routed to Returned queue. | | | Wait OFAC Queue | Send to Repair | Instructs GPP to send the message to the Repair (REPAIR) queue for manual adjustments. | | | Wait OFAC Queue | Cancel | Initiates the cancelation of the transaction, including earmark release and reverse posting, when required. | | | Compliance | OFAC Possible Hit Queue | Force | Instructs GPP to continue processing the message as if no hit was detected. | | OFAC Possible Hit Queue | Cancel | Initiates the cancelation of the transaction, including earmark release and reverse posting, when required. | | | OFAC Hit Queue | Send to Repair | Instructs GPP to send the message to the Repair (REPAIR) queue for manual adjustments. | | | Repair | Submit | Submits the transaction for reprocessing after user amendments to the transaction details, for example replace the Credit Account with a Suspense Account. | | Page 97 --- Fusion Global PAYplus | System Integration - Single Transactions | Business Guide # Interface Queue Action Description | Type | Compliance | Repair | Cancel | Initiates the cancelation of the transaction, including earmark release and reverse posting, when required. | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | | Online FX | FX Wait | Send to FX | Routes the message to the FX Repair (FXREPAIR) queue for manual adjustments. | | | Online FX | FX Wait | Processing | Opens the Processing Communications page for a user to resend the interface request, quoting the same event ID (if exists). | | | Online FX | FX Wait | Cancel | Initiates the cancelation of the transaction, including earmark release and reverse posting, when required. | | | Online FX | FX Rate | Submit | Submits the transaction for reprocessing after user amendments to the transaction details (for example, add Contract ID). GPP generates a Validate and Lock (VALLOCK) request and routes the transaction to FX Wait Queue (same as when the contract is included in original transaction). | | | Online FX | FX Rate | Get Deals | Sends a GETDEAL request (synchronic) to the external FX engine, and routes the transaction to FX Wait Queue. | | | • A positive response from the FX engine returns all valid contracts for the relevant currency pair and amount. Note: For a negative response the relevant error message is displayed. | | | | | | • GPP stores the contract information (contract reference, amount) and displays it on the transaction’s FX tab (Message Rates table). The FX tab should only display a single contract. All irrelevant contracts need to be deleted. | | | | | | If required, all the contracts can be deleted from the FX tab, and a dealer rate can be requested from the FX engine by clicking Get Rate. | | | | | | Online FX | FX Rate | Get Rate | Sends a GETRATE request (a dealer rate for the relevant currency and pair amount) to the external FX engine, and routes the transaction to FX Wait Queue. | | | In the response from the external FX engine, a respective Dealer Rate is auto-populated on the FX tab and a dialogue box appears displaying the rate and a countdown timer. The user has two options: | | | | | | • Approve: Accepts the quote, sends an Accept and Lock (ACCLOCK) request, and routes the transaction to FX Wait queue to wait for a response from the external FX engine. | | | | | | Note: The FX Engine sends two separate responses. For the transaction to continue processing the two responses must be | | | | | Page 98 --- # Fusion Global PAYplus # System Integration - Single Transactions # Business Guide | Interface | Queue | Action | Description | Type | | --------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | | Online FX | FX Rate | Cancel | Initiates the cancelation of the transaction, including earmark release and reverse posting, when required. | | | | Approve | Approves the quote, allowing the transaction to proceed. If the response is positive, otherwise the transaction is routed back to FX Repair queue. | | | | | | Reject | Rejects the quote, closes the dialogue box, sends a Reject Rate (REJRATE) response and clears the received rate from the FX tab table, allowing the user to continue to process the transaction. | | Note: If a negative response is received, a relevant error message is generated. Note: If the quote expires (the countdown timer on the dialogue box reaches 0 seconds), both Approve and Reject buttons are disabled. --- Appendix B: Glossary | Term | Description | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | CDB | Customer Database An external database hosted and maintained by the financial institution. | | Feeder | A customer-facing (front-end) system that enables GPP to input or capture transactions and transaction-related messages. | | Fndt Message | FuNDs Transfer Message A GPP proprietary message in XML format that includes the full set of information as received, enriched, computed, or manually updated for transaction or transaction-related message. Messages in this structure can be used to interact with financial institution systems and other supporting interfaces. | | GPP | Fusion Global PAYplus Finastra’s state-of-the-art global payment services hub. | | ISO | International Organization for Standards An international standard-setting body composed of representatives from various national standards organizations that promotes worldwide proprietary, industrial, and commercial standards. | | MEI | Message External Interaction A GPP database table that stores entries about external interface communications. | | PDO | Payment Data Object A specifically-structured data object that GPP requires for each transaction processed during the GPP transaction processing workflow. The data object holds all transaction data, including: • XML message date (original and enriched) • Relational data • Reference data • Rates, fees, errors, and so on | | PNL | Profit and Loss Account | | P\&L | A general ledger account through which the annual net profit or loss of a business is ascertained. | | SEPA | Single Euro Payments Area A European financial infrastructure that creates a zone in which Euro payments (or any other agreed upon currency) are considered domestic. | | SWIFT | Society For Worldwide Interbank Financial Telecommunications A member-owned cooperative that provides the communications platform, products, and services to connect over 8,600 banking organizations, securities institutions, and corporate customers in more than 208 countries. | Fusion Global PAYplus | System Integration - Single Transactions | Business Guide Page 100

SingleTrans