Business Guide GPP System Integration Single Transactions
User Manual: Pdf
Open the PDF directly: View PDF .
Page Count: 65
Download | |
Open PDF In Browser | View PDF |
GPP PAYplus System Integration - Single Transactions Technical Guide Product Version: 4.6.8 Catalog ID: GPP4.6-00-B54-01-201801 Copyright © 2009-2018 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: One Kingdom Street, Paddington, London W2 6BL, 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. 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 1.0 Summary of Changes Document Created 2.0 March 2016 Added Compliance and Online Foreign Exchange Interfaces 3.0 June 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 April 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 July 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 GPP PAYplus | System Integration - Single Transactions | Page 3 Table of Contents 1 INTRODUCTION .......................................................................................................................... 6 1.1 1.2 Documentation References .................................................................................................. 6 Target Audience .................................................................................................................... 7 2 HIGH LEVEL INTEGRATION FLOW .......................................................................................... 7 3 ACCOUNT LOOKUP INTERFACE ............................................................................................. 8 3.1 3.2 3.2.1 3.2.2 3.2.3 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.4 3.4.1 3.4.2 3.5 4 BALANCE INQUIRY INTERFACE ............................................................................................ 18 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.3.2 4.3.3 4.4 4.4.1 4.4.2 4.5 5 Overview ............................................................................................................................... 8 Processing .......................................................................................................................... 10 Workflow .......................................................................................................................... 10 Details .............................................................................................................................. 11 Response/Request Matching .......................................................................................... 13 Manual Handling ................................................................................................................. 13 Wait Queues .................................................................................................................... 14 Inactive Queues............................................................................................................... 14 Manual Handling Queues ................................................................................................ 14 Resume from Manual or Wait Statuses .......................................................................... 16 Business Setup and System Configuration ........................................................................ 16 Business Setup................................................................................................................ 16 System Configuration ...................................................................................................... 17 Message Data ..................................................................................................................... 18 Overview ............................................................................................................................. 18 Processing .......................................................................................................................... 18 Balance Check ................................................................................................................ 18 Earmark Release ............................................................................................................. 23 Automatic Retries ............................................................................................................ 24 Response/Request Matching .......................................................................................... 25 Manual Handling ................................................................................................................. 25 Wait Queues .................................................................................................................... 26 Inactive Queues............................................................................................................... 26 Manual Handling Queues ................................................................................................ 27 Business Setup and System Configuration ........................................................................ 29 Business Setup................................................................................................................ 29 System Configuration ...................................................................................................... 31 Message Data ..................................................................................................................... 32 COMPLIANCE INTERFACE ..................................................................................................... 32 5.1 5.2 5.2.1 5.2.2 5.2.3 5.3 5.3.1 5.3.2 5.4 Overview ............................................................................................................................. 32 Processing .......................................................................................................................... 33 Workflow .......................................................................................................................... 33 Details .............................................................................................................................. 33 Response/Request Matching .......................................................................................... 34 Manual Handling ................................................................................................................. 34 Wait Queues .................................................................................................................... 35 Manual Handling Queues ................................................................................................ 35 Business Setup and System Configuration ........................................................................ 36 GPP PAYplus | System Integration - Single Transactions | Page 4 5.4.1 Business Setup................................................................................................................ 36 5.4.2 System Configuration ...................................................................................................... 38 5.5 Message Data ..................................................................................................................... 39 6 FEEDER INTERFACE ............................................................................................................... 39 6.1 6.2 6.2.1 6.2.2 6.3 6.3.1 6.3.2 6.4 6.4.1 6.4.2 6.5 7 ONLINE FOREIGN EXCHANGE INTERFACE ......................................................................... 49 7.1 7.2 7.2.1 7.2.2 7.3 7.3.1 7.3.2 7.4 7.4.1 7.4.2 7.5 8 Overview ............................................................................................................................. 39 Processing .......................................................................................................................... 40 Workflow .......................................................................................................................... 40 Details .............................................................................................................................. 40 Manual Handling ................................................................................................................. 47 Wait Queues .................................................................................................................... 47 Manual Handling Queues ................................................................................................ 47 Business Setup and System Configuration ........................................................................ 47 Business Setup................................................................................................................ 47 System Configuration ...................................................................................................... 48 Message Data ..................................................................................................................... 49 Overview ............................................................................................................................. 49 Processing .......................................................................................................................... 50 Workflow .......................................................................................................................... 50 Details .............................................................................................................................. 51 Manual Handling ................................................................................................................. 51 Wait Queues .................................................................................................................... 52 Manual Handling Queues ................................................................................................ 52 Business Setup and System Configuration ........................................................................ 53 Business Setup................................................................................................................ 53 System Configuration ...................................................................................................... 54 Message Data ..................................................................................................................... 54 POSTING INTERFACE ............................................................................................................. 55 APPENDIX A: MANUAL ACTIONS PER QUEUES ............................................................................ 56 APPENDIX B: GLOSSARY .................................................................................................................. 64 GPP PAYplus | System Integration - Single Transactions | Page 5 1 Introduction Note: This document has not yet been certified for GPP V4.6; therefore, there may be inaccuracies in this document that may require amendments in the future. For more information, please contact your Finastra Project Manager. 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. 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. For the list of technical guides, see Documentation References. 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.1 Documentation References These GPP documents are referred to in this business guide. Document Name Comments 1. GPP Technical Guide Fndt Message Format Describes the full Fndt Message structure 2. GPP Technical Guide -Fndt Message Usage for Feeder Interface - Single Transaction Handoff Describes the minimal scope and additional optional sections that can be added for additional functionality, when using the Standard Fndt Message structure for Feeder request and acknowledgment. 3. GPP Technical Guide - Fndt Message Usage for Account Lookup Interface Describes the minimal scope and additional optional sections that can be added for additional functionality, when using the Standard Fndt Message structure for Account Lookup request and response. 4. GPP Technical Guide - Fndt Usage for Balance Inquiry Interface Message Describes the minimal scope and additional optional sections that can be added for additional functionality, when using the Standard Fndt Message structure for Balance Inquiry request and response. 5. GPP Technical Guide Fndt Message Usage for Posting Interface Describes the minimal scope and additional optional sections that can be added for additional functionality, when using the Standard Fndt Message structure for Posting request and response. 6. GPP Business Guide Posting Describes the business functionality of the Posting logic in GPP. This Business Guide includes information on the various Accounting models that can be supported, describes the required configuration and the manual handling around the Posting logic. 7. GPP Technical Guide - Fndt Usage for Compliance Interface Describes the minimal scope and additional optional sections that can be added for additional functionality, when GPP PAYplus | System Integration - Single Transactions | Page 6 Document Name Comments using the Standard Fndt Message structure for Compliance request and response. 8. GPP Interfaces Technical Guide Describes technical options and configuration of the different attributes in the Interfaces profile. 1.2 Target Audience This business guide is intended for business analysts and product managers that 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 Channels Best Practice Integration Layer Future Global PAYplus Internal Integration / Transformation Layer Queue List Feeder Ecosystem Interfaces Order Management File Processing Validation and Enrichment Single Payment Initiation Ack and Notification Balance Check Payment Execution Profile Upload Liquidity & Risk Management Mass Payments High Value Immediate Payments Account Posting SWIFTref upload Sanctions Infrastructure and Data Layer SWIFT RMA upload SWIFT Core Core Banking Banking Real Real Time Time FX FX Engine Engine Customer Advising Last Mile Solutions SAA SAA Customer Customer DB DB FX Core Services Reference Reference Data Data CIF Lookup Integration Layer Integration Layer Investigation Investigation Services & Uploads T2 Fees and Billing Euro1 Sanctions Sanctions // Fraud Fraud FATF FATF Notification Notification Internal Integration / Transformation Layer Integration Layer Billing Billing Engine Engine BAM BAM Replication DB CLEARING NETWORK Reporting Reporting GPP PAYplus | System Integration - Single Transactions | Page 7 3 Account Lookup Interface 3.1 Overview Account lookup is performed in GPP to retrieve account and customer information required for successful processing. This interface is always called within the context of a transaction. The interface may be invoked after debit/credit derivation and used for loading the debit/credit account details. 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. 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 expected to be 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 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 PAYplus | System Integration - Single Transactions | Page 8 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. GPP PAYplus | System Integration - Single Transactions | Page 9 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 Create account lookup request Evaluate Account Lookup Selection rules Account Lookup Rule found? Yes No Continue HV payment flow Wait Behavior WaitCDB Response received No User Action Resend from MEI screen Copy and resend original request with a new delivery timestamp (same EventID) Send to Repair Yes Successful response? Yes (MI_CDB_STS=P) Change account and Submit No (MI_CDB_STS=N) Posting restrictions No, Failure response Yes Posting Restrictions POSTREST Retry Post.Rest – to resend with retry monitor (new EventID) Repair Send to Repair User Action User Action Cancel Canceled Override Post. Rest (if stop flags is overridable) (new EventID) GPP PAYplus | System Integration - Single Transactions | Page 10 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). 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: - Incoming Debit (Collection) 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). 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: 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 GPP PAYplus | System Integration - Single Transactions | Page 11 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 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. 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 Account Lookup request is treated as failed. For more details on Interface Timeout behavior, see GPP Technical Guide - Interfaces document. 3.2.2.2.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 withof 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. GPP PAYplus | System Integration - Single Transactions | Page 12 3.2.2.2.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.2.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. 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.3 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.3.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 and , quoting, in the response, their value/s from the request + the P_MID. Specifically for Account Lookup the usage of 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 GPP PAYplus | System Integration - Single Transactions | Page 13 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 sync 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 only has the action of Cancel. GPP Processing: 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). 3.3.2 Inactive Queues When the relevant interface is not active, 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 the user only has the action of Cancel. GPP Processing: 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). 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). 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 set to P to allow skipping an additional invocation of the Account lookup, when message is reprocessed. GPP PAYplus | System Integration - Single Transactions | Page 14 - 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). Retry Post. Rest.: Instruct to retry the processing of the message GPP Processing: - Transaction is submitted back to try full reprocessing again, 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 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 GPP Processing: - The transaction is routed to 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. 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 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 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. I they are different (may happen when relevant GPP PAYplus | System Integration - Single Transactions | Page 15 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. GPP Processing: - The transaction is routed to 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 Whenever a transaction is submitted to resume processing after being stopped in a manual or wait statuses, and if the customer and account information were included in the Account Lookup Response, these details are reloaded again from this Account Lookup Response (stored in Processing Communications (MESSAGE_EXTERNAL_INTERACTION)). 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 These System Parameters are Business parameters, which are related to the Account Lookup functionality, when it provide Stop Flags or limitations on the account or customer. Name Description ASAP_POST_REST_CH ECK Specifies whether to perform the stop flags check as soon as possible. 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 (default) - 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. 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. GPP PAYplus | System Integration - Single Transactions | Page 16 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 3.4.1.3.1 Rules Account Lookup Rules Rules should be set to invoke the Account Lookup interface for the debit or credit account in cases they belong to a customer (relevant side MOP is BOOK), and as per specific financial institution business scenarios and conditions. Note: These rules are invoked whenever a debit or credit account of a message is not found in GPP, or is found but the External lookup check box is selected, indicating that the master copy for this account resides in the financial institution’s external system. 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. GPP PAYplus | System Integration - Single Transactions | Page 17 3.4.2.3 3.4.2.3.1 Rules 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 Balance Inquiry Interface 4.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. 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. 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. 4.2 Processing 4.2.1 Balance Check GPP PAYplus | System Integration - Single Transactions | Page 18 4.2.1.1 Workflow Start Balance Inquiry step Evaluate BI Bypass rules Create balance inquiry request BI Bypass Rule found? No Yes Continue HV payment flow Wait Behavior BIWaitQ Response received No Resend from MEI screen User Action Copy and resend original request with a new delivery timestamp Change message details and Submit (might involve invocation of earmark release) (same EventID) Yes Yes Send to Repair ‘Not Final’ response? No No (MI_BI_STS=N) Successful response? Insufficient Funds? Yes (MI_BI_STS=P) Posting restrictions? No No, Failure response Repair User Action Yes Cancel Yes Insufficient Funds NSF User Action Send to Repair Canceled P_RETRY_COUNT< MAXNSFRETRY? No Posting Restrictions POSTREST Clear P_RELEASE_INDEX (auto retry will not be performed anymore on this payment) Yes Set P_RELEASE_INDEX and increment P_RETRY_COUNT Retry NSF – to resend with retry monitor Send to Repair Force NSF Copy and resend original request with Force indicator + a new delivery timestamp (new EventID) GPP PAYplus | System Integration - Single Transactions | User Action Override Post. Rest (if stop flags is overridable) (new EventID) Retry Post.Rest – to resend with retry monitor (new EventID) Page 19 4.2.1.2 4.2.1.2.1 Details 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. 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. The Balance Inquiry can be invoked in two modes: 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. 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 Async, to the Wait Balance Inq. Response (BIWAITQ) status. 4.2.1.2.2 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 GPP PAYplus | System Integration - Single Transactions | Page 20 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. 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. 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 4.2.1.2.2.1 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. 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. 4.2.1.2.2.2 - 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. 4.2.1.2.2.3 Non-Final Response 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. GPP routes the transaction to the Repair (REPAIR) queue GPP PAYplus | System Integration - Single Transactions | Page 21 - 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. › 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. o - 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. GPP PAYplus | System Integration - Single Transactions | Page 22 4.2.2 Earmark Release 4.2.2.1 Earmark Release Workflow Continue Cancelation flow No User Action (from any queue) User Action (from Repair queue) Cancel Change message details and Submit Earmark previously placed? Check threshold of Debit Amount change Yes Major details changed? No More than accepted? Yes No 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 4.2.2.2 4.2.2.2.1 Details 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. The earmark release is invoked GPP PAYplus | System Integration - Single Transactions | Page 23 When a successful earmark hold response, quoting an Earmark Reference, was previously received, but posting for this amount is not yet performed. Notes: 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_ERAMARK_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. 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. 4.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. 4.2.3 Automatic Retries Automatic retries are not performed for all types of interfaces. This section describe the automatic retries which are supported for the Balance Inquiry interface. GPP PAYplus | System Integration - Single Transactions | Page 24 NSF event (frequency as per NSF_CHECK_FREQ Gather transactions with P_RELEASE_INDEX =NSF^HH:MM (as per Submit to the High Value flow 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. Notes: 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 it is recommended to not configure the interface with automatic retries. 4.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. 4.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 GPP PAYplus | System Integration - Single Transactions | Page 25 The description is per such specific manual queues. For a summary of actions per queue, see Appendix A: Manual Actions per Queues. 4.3.1 Wait Queues 4.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 sync 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: Force: Instructs GPP to continue processing 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 is released back to continue processing. Retry Bal. Inq.: Instructs GPP to retry the processing of the message 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 the message GPP Processing: - 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). 4.3.2 Inactive Queues When the relevant interface is not active, 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. 4.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 Nonactive behavior of SKIP, so that, GPP can proceed with the processing without checking the balance when the interface is not active. GPP PAYplus | System Integration - Single Transactions | Page 26 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 user only has the action of Cancel. GPP Processing: 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). 4.3.3 Manual Handling Queues 4.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). Retry Post. Rest.: Instruct to retry the processing of the message 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 GPP PAYplus | System Integration - Single Transactions | Page 27 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 GPP Processing: - 4.3.3.2 The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required (if the Balance Inquiry failed on the second leg (target debit account), and Posting was already performed on first leg). 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). 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 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. 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. GPP Processing: - The transaction is routed to cancellation flow, including earmark release, when required, reverse posting, when required (if the Balance Inquiry failed on the second leg (target debit account), and Posting was already performed on first leg). GPP PAYplus | System Integration - Single Transactions | Page 28 4.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. 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 › - - 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. › 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. The Posting entries are re-calculated and compared with previous entries not already marked as successful/reversed. I 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. GPP Processing: - 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. 4.4 Business Setup and System Configuration 4.4.1 Business Setup 4.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_CH ECK Specifies whether to perform the stop flags check as soon as possible. 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 GPP PAYplus | System Integration - Single Transactions | Page 29 Name Description 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 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 4.4.1.2 Profiles These are the details of the required setup in GPP profiles for the Balance Inquiry Interface. Note: For a detailed description of all the fields in the profiles, see GPP Online Help. 4.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. 4.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 4.4.1.3 4.4.1.3.1 Rules 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). 4.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. GPP PAYplus | System Integration - Single Transactions | Page 30 4.4.2 System Configuration 4.4.2.1 System Parameters There are no specific System Parameters, which are business parameters, required for the Balance Inquiry Interface. 4.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. 4.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. 4.4.2.2.2 Event Management The event NSF should be set for the automated retry task. Event Name Event Description Mode Minutes NSF Automatic Retry of NSF messages 0 GPP PAYplus | System Integration - Single Transactions | Batch Size 10 1 The frequency of the task should be equal to or less than the Page 31 Event Name Event Description Mode Minutes Batch Size setting of the NSF_CHECK_FREQ system parameter 4.4.2.3 4.4.2.3.1 System Rules 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). 4.5 Message Data There are no specific Message Attributes, errors and audit trails for this interface. 5 Compliance Interface 5.1 Overview Compliance with the laws, rules and standards that govern banking activities helps maintain a financial institution’s reputation with its shareholders, customers, employees and the investment community. Compliance laws, rules and standards include the prevention of money laundering and terrorist financing. A financial institution that knowingly participates in transactions intended by customers to avoid regulatory or financial reporting requirements, evade tax liabilities or facilitate illegal conduct exposes itself to serious compliance risk. The Office of Foreign Assets Control (OFAC) administers and enforces sanctions against countries and groups of individuals, such as terrorists and narcotics traffickers. These sanctions include the blocking of assets and trade restrictions to accomplish foreign policy and national security goals. GPP supports the compliance interface, which enhances a financial institution’s ability to implement the requirements of OFAC and similar regulatory bodies in other countries. GPP PAYplus | System Integration - Single Transactions | Page 32 5.2 Processing 5.2.1 Workflow Sanctions Flow SWIFT/Clearing/ CREATE GPP Payment Interface External Sanctions System Payment Processing Format Request WAIT_OFAC User Action Force Response Type No Hit First Response External Sanctions System Continue Processing Hit Failure/Invalid OFAC_POSSIB LE_HIT REPAIR Resend User Action Cancel Cancellation Flow Second Response Response Type No Hit Approved Failure/Invalid Seized Funds Continue Processing OFAC_HIT Cancel (Outgoing) User Action REPAIR Seized Send to Repair Return (Incoming) Return Flow 5.2.2 Details 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 two 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. GPP PAYplus | System Integration - Single Transactions | Page 33 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. 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. - 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 continues to be processed. - Return code is Hit: GPP routes the transaction to the Compex 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, 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 5.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 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.3 Manual Handling This section describes the various scenarios in which a single transaction may be stopped in relation with the Compliance interface. GPP PAYplus | System Integration - Single Transactions | Page 34 5.3.1 Wait Queues 5.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). 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: - GPP 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. Send to Repair: Instructs GPP to send the transaction 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 transaction. This is relevant for outgoing transactions only. GPP Processing: - The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required. 5.3.2 Manual Handling Queues 5.3.2.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: 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. This is relevant for outgoing transactions only. GPP Processing: - The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required. GPP PAYplus | System Integration - Single Transactions | Page 35 5.3.2.2 Compex 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. This is relevant for outgoing transactions only. GPP Processing: - The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required. 5.3.2.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 › Change the credit account to the account where the blocked funds need to be transferred. › Change the Credit MOP to BOOK. › Submit the transaction. Cancel: Instructs GPP to cancel the transaction. This is relevant for outgoing transactions only. GPP Processing: - The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required. 5.4 Business Setup and System Configuration 5.4.1 Business Setup 5.4.1.1 System Parameters There are no specific System Parameters, which are business parameters, required for the Compliance Interface. GPP PAYplus | System Integration - Single Transactions | Page 36 5.4.1.2 5.4.1.2.1 Profiles 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. This account may later in the flow be overridden by the Destination Account Enrichment rule. Note: For a detailed description of all the profiles, see GPP Online Help. 5.4.1.3 5.4.1.3.1 Rules 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 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 GPP PAYplus | System Integration - Single Transactions | Page 37 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 5.4.1.3.2 BYPASS 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). This is an example of the rule setup. The final setup should be done by the Financial Institution. Rule Attribute Setup Guidelines Rule Name Rule Sub Type (Relation Type) Description Attachment Rule conditions Rule Action 5.4.2 System Configuration 5.4.2.1 System Parameters There are no specific System Parameters, which are system parameters, required for the Compliance Interface. 5.4.2.2 Profiles There are no specific system profiles required for the Compliance Interface. Note: For a detailed description of all the profiles, see GPP Online Help. GPP PAYplus | System Integration - Single Transactions | Page 38 5.4.2.3 Rules 5.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. 5.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). 5.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) 6 Feeder Interface 6.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 GPP PAYplus | System Integration - Single Transactions | Page 39 attributes, and as long as the necessary information, per the different options, exists in this proprietary format. 6.2 Processing 6.2.1 Workflow Parsing and Capturing transaction and additional information provided HV Flow Processing FX Handling Resent for FX Handling triggered by event WAIT_TRIGGER_RATE Trigger Rate received and is favorable over calculated rate? Failed processing No Use calculated rate Yes Wait for better rate Change details and Submit Generate Acknowledgment Repair Wait Rate User Action Cancel Canceled 6.2.2 Details 6.2.2.1 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). 6.2.2.1.1 Parsing GPP parses the tags and fields of supported message types (for example, pain.001, pain.008 and MT103). 6.2.2.1.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 GPP PAYplus | System Integration - Single Transactions | Page 40 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 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. 6.2.2.1.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. 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. GPP PAYplus | System Integration - Single Transactions | Page 41 This table shows the mapping of the different fees attributes to the 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 GPP PAYplus | System Integration - Single Transactions | Page 42 - Fee amount in fee account currency - Fee amount in PNL account currency 6.2.2.1.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 retrieve 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)). 6.2.2.1.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: 7. 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. 8. 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. 9. If the fee account is defined in the relevant Account profile, GPP uses it as the fee account. 10. If the fee account is defined in the relevant Parties profile, GPP uses it as the fee account. 11. 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. 6.2.2.1.4 Capturing and Storing Message Rates When the message rates information is provided within the Feeder request (if using the Standard Fndt message, within the extension MsgRates), GPP captures it and stores it so that it can be used in the processing of the message. GPP populates the message rates structure in the PDO, and creates corresponding records in the MESSAGERATES table when the message is stored. This table shows the mapping of the different rates attributes to the MESSAGERATES entries. 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 CONVERSION_TYPE F_FC_CONVERSION_TYPE GPP PAYplus | System Integration - Single Transactions | Page 43 To MESSAGERATES Field Name Taken From FORWARD_CONTRACT F_FC_FORWARD_CONTRACT CUSTOMER_ID F_FC_CUSTOMER_ID MANUAL_SPREAD F_FC_MANUAL_SPREAD LATEST_DATE F_FC_LATEST_DATE For more information on the usage of rate information see Usage of Rates Related Information. 6.2.2.1.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. 6.2.2.1.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 tmessages 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. 6.2.2.2 6.2.2.2.1 Usage of Information Received During Processing 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 an outgoing transaction. 6.2.2.2.2 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. - When the MU_SET_DBT_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_DBT_MOP) is regarded by GPP as a suggested MOP. The MOP selection rules are GPP PAYplus | System Integration - Single Transactions | Page 44 invoked. These rules can be configured to include a condition on the provided P_DBT_MOP, and hence influence the final MOP selected by these rules. 6.2.2.2.3 Debtor and debit account (when provided): - Usage of Account and Customer Information 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): - 6.2.2.2.4 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). 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. 6.2.2.2.5 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). 6.2.2.2.5.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. 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 s, as the contract data overrides any other settings. GPP PAYplus | System Integration - Single Transactions | Page 45 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. 6.2.2.2.5.2 Counter Rate and Spread In a scenario when MsgRates element was received with F_FC_FORWARD_CONTRACT_TYPE set to 3, the rate received is regarded as an immediate rate that can be used if the transaction is processed STP (straight-through). If the transaction stops in REPAIR, NSF or any other manual or wait queues, the GPP rates are used instead of this rate, and GPP uses the F_FC_SPREAD and FC_SPREAD_UNITS in the contract to calculate a final rate. Note: This type of contract provides a customer with a rate, if used immediately, and protects the customer if the transaction stopped, with a good spread that is applied on the rate that is relevant when the transaction is released for processing. 6.2.2.2.5.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. 6.2.2.2.6 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. 6.2.2.3 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). GPP PAYplus | System Integration - Single Transactions | Page 46 See details on recommended configuration in Advising Type Selection (172). 6.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. 6.3.1 Wait Queues 6.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. 6.3.2 Manual Handling Queues 6.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. 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 Feeder Interface. 6.4.1.2 Profiles There are no specific GPP profiles required for the Feeder Interface. Note: For a detailed description of all the profiles, see GPP Online Help. 6.4.1.3 6.4.1.3.1 Business Rules Advising Type Selection (172) 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 that these notifications. GPP PAYplus | System Integration - Single Transactions | Page 47 A recommended set of notification can be provided when transaction reaches the following statuses: A success advise with ACTC in the 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 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 of the created pain.002, when transaction reaches CANCELLED, RETRUNED, REJECTED or NAK. 6.4.1.4 Permissions Permissions need to be granted to users that need to configure the rules related to the Feeder interface. 6.4.2 System Configuration 6.4.2.1 System Parameters There are no specific System Parameters, which are business parameters, required for the Feeder Interface. 6.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. 6.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. 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. 6.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 10 GPP PAYplus | System Integration - Single Transactions | 5 Page 48 6.4.2.3 6.4.2.3.1 Rules 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. 6.5 Message Data There are no specific Message Attributes, errors and audit trails for this interface. 7 Online Foreign Exchange Interface 7.1 Overview GPP uses a Currency Conversion mechanism to handle the conversion between two currencies, either by using a quoted rate between them or by using a cross currency to obtain a conversion rate. The exchange rate can be obtained from inside GPP or from an external system. This section provides details when the exchange rate is obtained from an external system. For a detailed description of the GPP processing for Currency conversions, see GPP Business Guide Currency Conversion. GPP PAYplus | System Integration - Single Transactions | Page 49 7.2 Processing 7.2.1 Workflow FX Payment SWIFT/Clearing/ CREATE Accounting System GPP Payment Payment Processing Account Lookup Continue Processing (using Indicative Rate) No External FX System Customer Data Account and Customer Info Processing Date? SCHEDULED queue Yes Contract received? No Yes Above Threshold? Yes No Response: Positive/Negative Response Type Positive Negative FX REPAIR FX Tab Options Get Deals Get Rate Accept/Reject Quote Lock Deal (Submit) Initial Requests: GETDEALS/GETRATE Initial Responses: Deals/Quote User Action Submit Customer Contracts, Rates Request: VALLOCK/RSSTP FXWAITQ Accept/Reject Rate FX Positive Responses Contract validated Rate auto-booked under threshold for Non-Dealing and predefined Dealing customers Secondary Request: ACCLOCK/REJRATE Negative FXWAITQ Response 1st ACCLOCK Type Positive Request: VALLOCK Customer Contracts, Rates REJRATE: Positive/Negative Negative Response Type Positive Continue Processing GPP PAYplus | System Integration - Single Transactions | VALLOCK/2nd ACCLOCK: Positive/Negative FX Responses VALLOCK upon Submit for contract 2nd ACCLOCK upon Accept for rate Page 50 7.2.2 Details 7.2.2.1 Transaction Received in GPP An external foreign exchange (FX) interface call is triggered in GPP after debit/credit side derivation, MOP and fees, and before posting. 1. GPP evaluates the Rate usage selection rules, applying the relevant Rate usage profile. The Rate Usage profile is configured with the external interface name 2. GPP applies an indicative rate as the standard rate, which is later overridden by the external received rate. 3. On processing GPP 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). 4. When GPP 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. 5. 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 Online FX request is treated as failed. For more details on Interface Timeout behavior, see GPP Technical Guide - Interfaces document 7.2.2.2 Manually Handled Transaction with Online FX Conversion A transaction that requires FX conversion can be created/repaired manually. On the transaction’s FX tab in the GPP User Interface, the user can either: Specify a single customer contract ID and its respective rate. Upon Submit, a Validate and Lock (VALLOCK) request is sent to the FX engine. Leave the FX tab empty. Upon Submit, a Rate Request STP (RRSTP) request is sent to the FX engine. Based on the response received from the FX engine, the transaction continues with the process or is routed to FX repair queue (see step 4 in Transaction Received in GPP). 7.2.2.3 Transaction with Debit and Credit Online FX Conversion GPP does not support conversion on both debit and credit side. When a transaction requires both Debit and Credit currency conversion, the transaction is routed to a manual queue for user intervention, for example FX Repair. 7.3 Manual Handling This section describes the various scenarios in which a single transaction may be stopped in relation with the Online FX interface. GPP PAYplus | System Integration - Single Transactions | Page 51 7.3.1 Wait Queues 7.3.1.1 FX Wait Queue A single transaction is stopped in this queue when it is waiting for a response from the external FX engine. In this queue the following actions can be performed: Send to FX Repair: Instructs GPP to send the transaction to the FX Repair (FXREPAIR) queue for manual adjustments. GPP Processing: - The transaction is routed to the FX Repair (FXREPAIR) queue. Processing Communications: Opens the Processing Communications page to allow instructing to resend the interface request. GPP Processing: - The Processing Communications page is opened for user to resend the interface request, quoting the same event ID (if exists). Cancel: Instructs GPP to cancel the transaction. This is relevant for outgoing transactions only. GPP Processing: - The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required. 7.3.2 Manual Handling Queues 7.3.2.1 FX Rate Repair Queue A transaction is routed to the FX Repair queue, in order to repair the FX information, so that it can continue to be processed. In this queue the following actions can be performed: Submit: Make amendments to the details, and Submit it for re-processing. To add a Contract ID: - Input Contract ID in FX tab. - Submit the payment. - GPP generates a Validate and Lock (VALLOCK) request and routes the payment to FX Wait Queue (same as when the contract is included in original payment) Get Deals: Define the relevant contract and Submit it for re-processing. - GPP sends a GETDEAL request (synchronic) to the 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. - Click Submit, the Validate and Lock (VALLOCK) request is sent to the external FX engine. - GPP routes the transaction to FX Wait Queue. GPP PAYplus | System Integration - Single Transactions | Page 52 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: Request a dealer rate for the relevant currency and pair amount. GPP Processing - GPP 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 Processing: - The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required. 7.4 Business Setup and System Configuration 7.4.1 Business Setup 7.4.1.1 System Parameters These System Parameters are business parameters, which are related to the FX functionality. Name Description FX_THRESHOLD_AFTE R_SCHEDULE Determines if the FX threshold defined in a Rate Usage profile is checked on the actual processing date of the transaction (after schedule). Y - FX threshold is checked by GPP on the transaction 's processing date N - FX threshold is checked by GPP when the Rate Usage profile associated with the transaction is evaluated 7.4.1.2 Profiles These are the details of the required setup in GPP system profiles for the FX Interface. Note: For a detailed description of all the profiles, see GPP Online Help. 7.4.1.2.1 Rate Usage 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 under Above threshold go to field. GPP PAYplus | System Integration - Single Transactions | Page 53 Example: Profile name: HV_EFX Profile description: External FX Rate Usage Rate type: STANDARD Rate interface name: EFX_OUT_ASYNC Above threshold goes to: FX Rate Repair 7.4.1.3 Rules Rate Usage for Credit Side Conversion, Rate Usage for Debit Side Conversion and Rate Usage for Base Conversion should be setup to select the external FX Rate usage. The rules should be set up based on the Financial Institution’s business requirements. 7.4.2 System Configuration 7.4.2.1 System Parameters There are no specific System Parameters, which are system parameters, required for the FX Interface. 7.4.2.2 Profiles There are no specific GPP system profiles required for the FX Interface. Note: For a detailed description of all the profiles, see GPP Online Help. 7.4.2.3 7.4.2.3.1 Rules Interface Selection Rule Interface selection rules can be configured according to the Financial Institution’s requirements, in order to select the relevant Online FX interface, specifically when multiple interfaces are used. A-Sync interface is selected based on the Rate usage profile setup. Sync interface is selected based on user’s manual action (Get rate or Get deals). This is an example of the rule setup. The final setup should be done by the Financial Institution. Rule Attribute Setup Guidelines Rule Name HV_EFX_SYNC Rule Sub Type (Relation Type) 0 Description Interface selection for Sync FX interface Attachment *** Rule conditions [Button ID] In Get Deals, Get Rate Rule Action EFX_OUT_SYNC 7.5 Message Data There are no specific Message Attributes, errors and audit trails for this interface. GPP PAYplus | System Integration - Single Transactions | Page 54 8 Posting Interface For information on the business functionality and business setup for the posting logic and interface, see the GPP Posting Business Guide. GPP PAYplus | System Integration - Single Transactions | Page 55 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 Force Inq. Response 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 Retry Bal. Inq. Inq. Response 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 Send to Repair Inq. Response GPP sends the message to the Repair queue for manual adjustments Balance Inquiry Wait Balance Cancel Inq. Response 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 The automated WAIT_TRIGGER_RATE event releases the transaction for re-computation of the It is an event and not an action GPP PAYplus | System Integration - Single Transactions | Page 56 Interface Type Queue Action Description rate for it, in a scenario in which it is stopped in this queue, waiting for an up-to-date rate. Such a scenario may be, a scenario in which Feeder Interface provided a Target Rate, and the computed GPP rate was not favorable to this Target Rate. Posting Wait Posting 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. Posting Wait Posting 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 Posting 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 CDB 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 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 Posting Cancel Initiates the cancelation of the transaction. GPP PAYplus | System Integration - Single Transactions | Page 57 Interface Type Queue Action Description The transaction is routed to cancellation flow, including earmark release, when required, and reverse posting, when required (if Posting cannot be performed on the second leg, and Posting was already performed on first leg). 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. I they are different (may happen when relevant transaction attributes (account, amount, value date) were changed), reversed posting entries are created for these nonfinal 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. GPP PAYplus | System Integration - Single Transactions | Page 58 Interface Type Queue Action Inquiry / Posting Description The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required. 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. GPP PAYplus | System Integration - Single Transactions | Page 59 Interface Type 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 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) due to user decision – either force from Insufficient Funds (NSF) or restrictions GPP PAYplus | System Integration - Single Transactions | Page 60 Interface Type Queue Action Description overridden from Posting Restrictions (POSTREST). If required, but not in the minimal request scope, the Posting request can include, within the added Monitors extension, the specific monitor, to indicate which of these was selected, (for forcing insufficient funds -MU_NSF_FORCE_STS = 1 or for overriding restrictions MU_STOP_FLAGS_OVERRIDE_STS = O). The transaction is routed to Wait Posting (MP_WAIT) pending response from HOST system. Note: This button is only available to allow a user to override the restriction, when the transaction was stopped due to an overridable Stop Flag. Account Lookup / Balance Inquiry / Posting Posting Restrictions 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. Account Lookup / Balance Inquiry / Posting Posting Restrictions Send to Repair Sends the message to the Repair queue for manual adjustments. Account Lookup / Balance Inquiry / Posting Posting Restrictions Cancel Initiates the cancelation of the transaction. The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required. GPP PAYplus | System Integration - Single Transactions | Page 61 Interface Type Queue Action Description Posting 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. Posting Posting Exception Queue Send to Repair Sends the message to the Repair queue for manual adjustments. Posting Posting Exception Queue 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 Communications Opens the Processing Communications page for a user to resend the interface request, quoting the same event ID (if exists). Compliance Wait OFAC Queue Force Instructs GPP to continue processing the message as if no hit was detected. Compliance 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. Compliance Wait OFAC Queue Send to Repair Instructs GPP to send the message to the Repair (REPAIR) queue for manual adjustments. Compliance Wait OFAC Queue Cancel Initiates the cancelation of the outgoing 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. Compliance OFAC Possible Hit Queue Cancel Initiates the cancelation of the outgoing transaction, including earmark release and reverse posting, when required. Compliance OFAC Hit Queue Send to Repair Instructs GPP to send the message to the Repair (REPAIR) queue for manual adjustments. Compliance Repair Submit Submits the transaction for reprocessing after user amendments to the transaction details, for GPP PAYplus | System Integration - Single Transactions | Page 62 Interface Type Queue Action Description example replace the Credit Account with a Suspense Account. Compliance Repair Cancel Online FX FX Wait Queue Send to FX Repair Routes the message to the FX Repair (FXREPAIR) queue for manual adjustments. Online FX FX Wait Queue Processing Communications Opens the Processing Communications page for a user to resend the interface request, quoting the same event ID (if exists). Online FX FX Wait Queue Cancel Initiates the cancelation of the transaction, including earmark release and reverse posting, when required. Online FX FX Rate Repair Queue 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 Repair Queue 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 are 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 Repair Queue 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 Initiates the cancelation of the outgoing transaction, including earmark release and reverse posting, when required. GPP PAYplus | System Integration - Single Transactions | Page 63 Interface Type Queue Action Description 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 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. Online FX FX Rate Repair Queue Cancel Initiates the cancelation of the transaction, including earmark release and reverse posting, when required. 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 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. PDO Payment Data Object A data object that holds all transaction data, including: XML message date (original and enriched) Relational data Reference data GPP PAYplus | System Integration - Single Transactions | Page 64 Term Description Rates, fees, errors, and so on PNL P&L Profit and Loss Account 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. GPP PAYplus | System Integration - Single Transactions | Page 65
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Language : en-US Tagged PDF : Yes XMP Toolkit : Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26 Format : application/pdf Creator : Finastra Description : System Integration - Single Transactions Title : Business Guide Create Date : 2018:01:01 15:24:12+02:00 Creator Tool : Microsoft® Word 2016 Modify Date : 2018:01:15 11:24:01+02:00 Metadata Date : 2018:01:15 11:24:01+02:00 Producer : Microsoft® Word 2016 Document ID : uuid:be564b6b-8e94-410f-a4f0-f68c4cf82485 Instance ID : uuid:1f11b497-caef-420b-82a6-fe0fb83ff2fa Page Mode : UseOutlines Page Count : 65 Author : Finastra Keywords : Global, PAYplus Subject : System Integration - Single TransactionsEXIF Metadata provided by EXIF.tools