Business Guide GPP System Integration Files
User Manual: Pdf
Open the PDF directly: View PDF .
Page Count: 47
Download | |
Open PDF In Browser | View PDF |
GPP PAYplus System Integration - Files Technical Guide Product Version: 4.6.8 Catalog ID: GPP4.6-00-B55-01-201801 Copyright © 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 Summary of Changes 1.0 Aug 2017 Document created GPP PAYplus | System Integration - Files | Page 3 Table of Contents 1 INTRODUCTION .......................................................................................................................... 5 1.1 1.2 Documentation References .................................................................................................. 5 Target Audience .................................................................................................................... 5 2 HIGH LEVEL INTEGRATION FLOW .......................................................................................... 6 3 INTERFACE TYPES .................................................................................................................... 6 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 4 Overview ............................................................................................................................... 6 Interface Transmission Modes .............................................................................................. 6 Account Lookup Interface ..................................................................................................... 7 Overview............................................................................................................................ 7 Processing ......................................................................................................................... 8 Manual Handling.............................................................................................................. 15 Business Setup and System Configuration ..................................................................... 17 Message Data ................................................................................................................. 19 Balance Inquiry Interface .................................................................................................... 19 Overview.......................................................................................................................... 19 Processing ....................................................................................................................... 20 Manual Handling.............................................................................................................. 26 Business Setup and System Configuration ..................................................................... 27 Message Data ................................................................................................................. 30 Compliance Interface .......................................................................................................... 30 Overview.......................................................................................................................... 30 Processing ....................................................................................................................... 30 Manual Handling.............................................................................................................. 33 Business Setup and System Configuration ..................................................................... 35 Message Data ................................................................................................................. 37 BULK INTERFACE .................................................................................................................... 38 4.1 4.2 4.2.1 4.3 4.4 4.4.1 4.4.2 Overview ............................................................................................................................. 38 Processing .......................................................................................................................... 38 Details .............................................................................................................................. 38 Manual Handling ................................................................................................................. 40 Business Setup and System Configuration ........................................................................ 40 Business Setup................................................................................................................ 40 System Configuration ...................................................................................................... 40 APPENDIX A: MANUAL ACTIONS PER QUEUE ............................................................................... 42 APPENDIX B: GLOSSARY .................................................................................................................. 46 GPP PAYplus | System Integration - Files | Page 4 1 Introduction 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 called the FuNDs Transfer (Fndt) Message, which is used with the interfaces. This business guide describes the business functionality as part of mass payment (MP) 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. 1.1 Documentation References The following table describes the documents referenced in this business guide. Document Name Description GPP Fndt Message Format Technical Guide Describes the full Fndt Message structure. GPP Fndt Message Usage for Account Lookup Interface Technical Guide Describes the minimal scope and additional optional sections that can be added for additional functionality, when using the standard Fndt Message structure for individual Account Lookup interface requests and responses. Note: In file handling, the default method sends a bulk file that contains multiple interface messages. GPP Fndt Message Usage for Balance Inquiry Interface Technical Guide Describes the minimal scope when using the standard Fndt Message structure for individual Balance Inquiry Interface requests and responses. Note: In file handling, the default method sends a bulk file that contains multiple interface messages. GPP Fndt Message Usage for Compliance Interface Technical Guide Describes the minimal scope when using the standard Fndt Message structure for individual Compliance Interface requests and responses. Note: In file handling, the default method sends a bulk file that contains multiple interface messages. GPP Fndt Message Usage for Posting Interface Technical Guide Describes the minimal scope when using the standard Fndt Message structure for individual Posting Interface requests and responses. Note: In file handling, the default method sends a bulk file that contains multiple interface messages. For more information about bulk file handling, see Bulk Interface. 1.2 Target Audience This business guide is intended for business analysts and product managers who need to understand the integration capabilities, including the configuration and utilization, for each interface that GPP supports. GPP PAYplus | System Integration - Files | Page 5 2 High Level Integration Flow GPP supports invocation of various interfaces during its mass 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 SWIFTref upload Sanctions (Roadmap) 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 Account Posting Customer Customer DB DB FX (Roadmap) 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 3 Interface Types 3.1 Overview GPP interface support enables GPP to communicate with various external financial institution systems. During transaction processing, GPP invokes specific interfaces that enable GPP to generate and transmit requests to external systems. GPP is also able to receive and process incoming responses received in response to outgoing requests. A financial institution can configure GPP to transmit interface requests and receive responses in a Bulk or Single mode. For more information, see Interface Transmission Modes. 3.2 Interface Transmission Modes A financial institution can configure GPP to transmit interface requests and receive responses in the following modes: GPP PAYplus | System Integration - Files | Page 6 Bulk: GPP generates each interface request and stores them for bulk transmission. The specific interface generates a request in the required format but does not transmit it to the designated financial institution system. Instead, GPP stores each request in a database table until a defined sending time. At the sending time, the GPP Bulk interface generates a bulk file that includes all the stored requests and transmits the file to the external system. The bulk file conforms to the required format that includes a structured header and body. The body contains one or more occurrences of the relevant request in the required format. For information, see Bulk Interface. Single: GPP generates and transmits each interface request individually. The specific interface generates a request in the required format and transmits it to the designated financial institution system. Note: The Bulk mode is the GPP default configuration. 3.3 Account Lookup Interface 3.3.1 Overview The GPP Account Lookup interface enables GPP to retrieve account and customer information required during transaction and transaction-related message processing. When processing a file that contains multiple transactions, GPP can invoke the interface for each transaction during individual transaction processing. But on the source side, where an account in the PmntInf level is the same for all the transactions in the level, GPP invokes the interface for the first transaction only and stores the received information in the system cache. For all subsequent transactions in the level, GPP retrieves the account information from the cache. GPP might invoke the interface after debit/credit derivation to load debit/credit account details. The GPP default configuration transmits Account Lookup interface requests and receives responses in the Bulk mode. For more information, see Interface Transmission Modes. Note: The account and customer attributes (F_ fields) retrieved using the Account Lookup can be used in processing rules during the transaction processing. However, after a transaction reaches a final status, this information is not kept in the context of the transaction. As in file handling, the default behavior sends the interfaces as a bulk and does not save each request and response in the MESSAGE_EXTERNAL_INTERACTIONS table, meaning they cannot be viewed in a transaction context via the Processing Communication page. For more information about the Bulk Interface, see Bulk Interface. GPP invokes Account Lookup business rules when the credit account or the debit account is not 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 invoked rules, if the Action field of a relevant rule is defined as External, GPP invokes the Account Lookup interface. Note: GPP does not invoke the Account Lookup interface for Fee accounts. If GPP invokes the Account Lookup interface and is configured to work in asynchronous mode, GPP does the following Sets the transaction with a CDBWAIT status Routes the transaction to the Wait CDB Response queue Stops processing the transaction until receipt of the interface response The Account Lookup response might include the following information: GPP PAYplus | System Integration - Files | Page 7 Holding customer identification, name, and address details (country, state, city, zip code, street address) Customer and account categorization that might affect processing (such as foreign exchange (FX) and fees) Booking entity assigned to the account (accounting system in which the account is managed) Account type, as defined in the relevant GPP Account Types profile Posting restriction that might exist on the account If a processing error occurs on the host, the interface returns a response that includes details or the error, which can be caused by a technical or functional issue. The Account Lookup interface supports the standard Fndt request and response message format. For more information, see the GPP Fndt Message Usage for Account Lookup Interface Technical Guide. For information about the types of responses that GPP can receive from the Account Lookup interfaces, see Interface Response Types. GPP can also support proprietary formats to meet specific financial institution business requirements. Proprietary format support might require additional mapping and is dependent on the presence of message attributes required by GPP. 3.3.2 Processing 3.3.2.1 High Level Flow GPP might invoke the Account Lookup interface during Pre-Processing Transactions in various file processing end-to-end flows, such as during Mass Payment and Order Management. GPP invokes the Account Lookup interface for the following accounts: Credit: Invoked for the credit account only Debit: Invoked for the debit account only Both: Invoked for both the credit and debit accounts for an On-Us transaction GPP might invoke the Account Lookup interface on the following sides: Source Account: For the debit account in outgoing credit transfers and the credit account in outgoing direct debits within the Pre-Processing Transactions stage in the various file handling flows Target Account: For credit account in outgoing or incoming credit transfers and debit account in outgoing or incoming direct debits within the Execution stage in the various file handling flows GPP PAYplus | System Integration - Files | Page 8 The following shows the Account Lookup in the transaction processing workflow. Start Dr/Cr side Processing No In PreProcessing and Target side? Yes Load account and party from GPP DB Credit Side Enrichment with DUMMY Account Yes Success External lookup set? No No Yes Create account lookup request Yes Account Lookup Rule found? Yes A-Sync interface? No Continue file transaction flow No Wait Behavior WaitCDB Response received Yes Successful response? Yes (MI_CDB_STS=P) Change account and Submit No (MI_CDB_STS=N) Posting restrictions No, Failure response Repair User Action Cancel Yes Posting Restrictions POSTREST User Action Send to Repair Canceled Retry Post.Rest – to resend with retry monitor (new EventID) Override Post. Rest (if stop flags is overridable) (new EventID) GPP PAYplus | System Integration - Files | Page 9 3.3.2.2 3.3.2.2.1 Details Source Account Lookup Request - Pre-Processing Transactions During Pre-Processing Transactions of the Outgoing File handling flow for an individual (I) transaction, GPP performs the Load Party service for the source debit and credit accounts (debit account in outgoing credit transfers and credit account in outgoing direct debits) if the debtor/creditor account identification is provided in the transaction. GPP searches the database to determine whether the source account exists in GPP and invokes Account Lookup rules as follows: If the account does not exist in GPP If the account exists and is defined to be rechecked in the host (External Lookup is selected) If GPP invokes Account Lookup rules and determines that a rule’s conditions match the transaction, GPP executes the rule’s defined Action. If the Action is defined as External, GPP does the following: Invokes the Account Lookup interface as defined in the relevant Interface Selection rule Creates an Account Lookup interface request If defined, GPP can create the request in the Fndt Message Standard format. For more information, see the GPP Fndt Message Usage for Account Lookup Interface Technical Guide. Sends the request to the integration system in synchronous mode Note: GPP cannot send an asynchronous interface request during Pre-Processing Transactions. Note: If a transaction’s account is an IBAN number, GPP sends it and the deconstructed Account Number in the Account Lookup interface request, which enables the financial institution’s system to identify it. GPP can include in the request a unique 16-character Event ID each time a transaction triggers the Account Lookup interface. The request contains one of the following: New Event ID: If the request is an override or a re-invocation after a manual or wait queue request. Original Event ID: If the request is a resend. Note: If using the GPP Standard Account Lookup format, the Event ID is in the EventID tag in the request header section. GPP generates an Event ID if the EVENT_ID_GENERATION field is set to 1 in the INTERFACE_TYPES entry. GPP generates it using an algorithm that is similar to the Message ID (MID) algorithm, which includes letters, numbers, and date and time. GPP saves the Event ID, which can also be used in the D_MEI_EVENT_ID logical field. In file handling flows, GPP default behavior uses the Bulk Interface functionality and sends requests in a bulk file. In this case, GPP does not store requests in the GPP database. For more information about the bulk interface, see Bulk Interface. A financial institution can alter the default behavior and send interface messages individually. In this case, the INTERFACE_TYPES table can be configured to store requests in the MESSAGE_EXTERNAL_INTERACTION table, which authorized users can view via the GPP UI Processing Communications page, and also stores the Event ID in the EVENT_ID column of the entry. Note: If configured as individual and with a store instruction GPP stores information for all requests, even if the information for a particular request was retrieved from the system cache. For all scenarios of Account Lookup interface invocation, if a transaction, or the Sub Batch entry representing the group of transactions, is released from a manual or wait queue (for example GPP PAYplus | System Integration - Files | Page 10 Schedule), GPP sends an additional validation request via the Account Lookup interface to the host system to ensure the account is valid. 3.3.2.2.2 Target Account Lookup Request - Pre-Processing Transactions During Pre-Processing Transactions of the Outgoing File handling flow for an individual (I) transaction, GPP performs the Load Party service for the target debit and credit accounts (credit account in outgoing credit transfers and debit account in outgoing direct debits) if the debtor/creditor account identification is provided in the transaction. During Pre-Processing Transactions, GPP uses a dummy account number, to bypass the Account Lookup interface. GPP invokes a Credit Account Enrichment rule with Usage of CDB_DUMMY_ACCOUNT to temporarily store the dummy account number instead of the actual account number. When such a dummy account is selected - an indicator is set on the transaction level to indicate that it is just a temporary assignment. Based on this indicator GPP will restore the actual account number in place of the dummy account number and, if required, will invoke the Account Lookup interface during the Execution stage, as described in Target Account Lookup Request - Execution. 3.3.2.2.3 Account Lookup Response Handling - Pre-Processing Transactions GPP expects to receive a response for every request sent to the Account Lookup interface. GPP can receive a Successful or Failure response, as described in Interface Response Types. Upon receipt of the response, GPP does the following: Parses the response and validates that it is structurally valid against the defined structure, either the standard Fndt Message or a financial institution-specific proprietary structure defined for the interface. Matches the response to the corresponding request, as described in Request and Response Matching. Stores the received information in the system cache, which can be used for processing subsequent transactions with the same account. GPP stores the information with a key generated from the account number, account currency/settlement currency, account office, File ID, and account lookup side (debit or credit). GPP stores the information only if not already stored in the cache. Checks Interface configuration settings and does one of the following: - Does not store the received information if using the default configuration to implement bulk interface response handling. For more information, see Bulk Interface. - Stores the received information in the GPP MESSAGE_EXTERNAL_INTERACTION database table if configured for individual interface response handling. Note: The default GPP configuration for file handling is to send interface requests and receive responses in bulks. This configuration can be changed to meet financial institution requirements. In addition, the default GPP configuration for file handling is not to store individual interface responses in the GPP database, which can also be changed to meet financial institution requirements. In this case GPP would store requests and responses for all related transactions, even if the information for an individual request was retrieved from the system cache. Authorized GPP users can then view the stored requests and responses via the GPP UI Processing Communications page. If a response was previously received for the matched request (manual retry was performed and the original response was received after the retry request was sent), GPP ignores the received response (but saves it in the GPP database if configured to do so) and continues transaction processing. Updates the Audit Trail of the transaction to indicate that GPP received a response. GPP PAYplus | System Integration - Files | Page 11 Adds a response error description to the transaction’s Error Log if GPP receives a failure response. Evaluates the received response to determine continued transaction processing. For more information, see Successful Response and Failure Response. If GPP does not receive a response within the configured timeout period, and as the default GPP configuration of the Interface Type for File Handling is not to retry on timeout, the interface becomes inactive and the Account Lookup request is processed as a failure response. If this occurs during PreProcessing Transactions, GPP rolls back the entire file, including all information stored in the database. For more information, see the GPP Interfaces Technical Guide. 3.3.2.2.3.1 Successful Response Upon receipt of a successful response, GPP does the following: Captures the information in the received response and stores I transaction information in the transaction data. - An Account Lookup request cannot include a request for fee information if sent during PreProcessing Transactions on the source side for an outgoing credit transfer or direct debit. - If an Account Lookup response contains contact information, GPP stores a contact details occurrence per each contact, reflecting its association to either the debit or credit account or party. Account information is saved for re-use for the processing of other transactions with a key generated using the account number, account currency/settlement currency, account office, file ID, and account lookup side (debit/credit). Continues transaction processing. 3.3.2.2.3.2 Failure Response Upon receipt of a failure response (functional, technical, or timeout), GPP does the following: Captures the error reasons included in the response. If required, GPP maps the provided errors to GPP errors, based on a predefined error mapping conversion. Adds the errors to the transaction Error Log. For each I transaction checked against the designated cache with same account, if a failure response was received, the error is assigned to all relevant I transactions and added to their transaction Error Logs. If a response contains technical error or a timeout was reached, GPP does the following: - Sets the interface status to Inactive. - Sets the file status to FileRolled and updates the File Summary record. An authorized user can cancel or reprocess a file that has a FileRolled status. - Clears all payment relevant data for the file, including for transactions that receive a successful response. - Generates an interface-level error to the INTERFACE_ERROR_LOG. Routes the transaction to the relevant queue (Posting Restrictions (POSTREST) or Rejected (RJECTED)) based on the response received. For more information about manual options, see Posting Restrictions (POSTREST) Queue. Note: GPP periodically refreshes the system cache. In addition, upon completion of file processing, GPP clears the cache of all related accounts. GPP PAYplus | System Integration - Files | Page 12 3.3.2.2.4 Target Account Lookup Request - Execution During the Execution stage of the Outgoing File handling flow for an I transaction, GPP performs the Load Party service for the target debit and credit accounts (credit account in outgoing credit transfers and debit account in outgoing direct debits) if the debtor/creditor account identification is provided in the transaction. During this stage, based on this indicator that a dummy account was previously derived, GPP restores the actual account number, instead of the dummy account number (see Source Account Lookup Request - Pre-Processing Transactions) used during Pre-Processing Transactions. GPP searches the database to determine whether the target account exists in GPP and invokes Account Lookup rules as follows: If the account does not exist in GPP If the account exists and is defined to be rechecked in the host (External Lookup is selected) If GPP invokes Account Lookup rules and determines that a rule’s conditions match the transaction, GPP executes the rule’s defined Action. If the Action is defined as External, GPP does the following: Invokes the Account Lookup interface as defined in the relevant Interface Selection rule. Creates an Account Lookup interface request. If defined, GPP can create the request in the Fndt Message Standard format. For more information, see the GPP Fndt Message Usage for Account Lookup Interface Technical Guide. Sends the request to the integration system in asynchronous mode as per GPP default configuration (unless GPP is configured differently to meet financial institution-specific requirements). Sets the transaction with a CDBWAIT status and routes it to the Wait CDB Response queue until a response is received from the interface. 3.3.2.2.5 Account Lookup Response Handling - Execution GPP expects to receive a response for every request sent to the Account Lookup interface. GPP can receive a Successful or Failure response, as described in Interface Response Types. Upon receipt of the response, GPP does the following: Parses the response and validates that it is structurally valid against the defined structure, either the Standard Fndt Message or a financial institution-specific proprietary structure defined for the interface. Matches the response to the corresponding request, as described in Request and Response Matching. Stores the received information as follows: - Successful Response: Stores the received account and customer information, such as account, customer, contacts, and fees (if included). - Failure Response: Stores the reason for the failure. Checks interface configuration settings and does one of the following: - Does not store the response received in a bulk interface response, which is the default configuration for file handling flows. For more information, see Bulk Interface. - If configured to do so, GPP stores the individual responses in the MESSAGE_EXTERNAL_INTERACTION database table. Note: The default GPP configuration for file handling is to send interface requests and receive responses in bulks. This configuration can be changed to meet financial institution requirements. In addition, the default GPP configuration for file handling is not to store individual interface GPP PAYplus | System Integration - Files | Page 13 responses in the GPP database, which can also be changed to meet financial institution requirements. In this case GPP would store requests and responses for all related transactions, even if the information for an individual request was retrieved from the system cache. Authorized GPP users can then view the stored requests and responses via the GPP UI Processing Communications page. If a response was previously received for the matched request (automatic or manual retry were performed and the original response was received after the retry request was sent), GPP ignores the received response (but saves it in the GPP database if configured to do so) and continues transaction processing. Updates the Audit Trail of the transaction to indicate that GPP received a response. If GPP receives a failure response, GPP adds a response error description to the transaction’s Error Log. Evaluates the received response to determine continued transaction processing. For more information, see Successful Response and Failure Response. The Interface Types for File Handling default configuration does not use timeout functionality. If GPP does not receive a response to a request, the transaction remains in the wait queue until receipt of a response. Manual handling is required to make the interface inactive. Note: GPP executes the target-side Account Lookup interface in asynchronous mode and (because of the large number of customer accounts in the GPP database) improves performance by not implementing timeout and retry functionality for the interface. 3.3.2.2.5.1 Successful Response Upon receipt of a successful response, GPP does the following: Captures the information in the received response and stores I transaction information in the transaction data. Matches the response to the corresponding transaction in the Wait CDB Response queue. Continues transaction processing. 3.3.2.2.5.2 Failure Response Upon receipt of a failure response, GPP does the following: Captures the error reasons included in the response. If required, GPP maps the provided errors to GPP errors, based on a predefined error mapping conversion. Adds errors to the transaction Error Log. If the received response contains a functional or technical error, GPP does the following: - 3.3.2.3 If the default Straight-Through Processing (STP) Workflow rule is defined, as the GPP default behavior for file handling flows for any failure other than Posting Restrictions, GPP does the following: › Sets the transaction with a REJECTED status › Routes the transaction to the Rejected queue › Invokes the reject/cancel processing flow, which can include reverse accounting (if required) If a posting restriction response was received - GPP routes the transaction to the Posting Restrictions (POSTREST) queue. For more information, see Manual Handling. Interface Response Types GPP uses the response received from the Account Lookup interface to determine continued transaction processing. The interface returns one of the following responses: GPP PAYplus | System Integration - Files | Page 14 Successful: Upon receipt of a successful response, GPP stores the returned account information and continues transaction processing. Failure: Upon receipt of a failure response, either technical or functional, GPP sets the transaction with a Repair (REPAIR) status and routes it to the Repair queue for manual handling. 3.3.2.4 Usage of Information Received During Processing During Pre-Processing Transactions, GPP uses the information received in the Account Lookup response for the following: Account validation. Debtor and creditor information enrichment. For example, the name and address information required in the transaction can be submitted to the clearing scheme. Fee calculation: For more information, see Fees Information. Balance inquiry. Posting restriction check, if restrictions were reported. Posting entries generation, (including entries for the fees reported in the response) and posting interface. Advising, using the contact information provided in the response. 3.3.2.5 Fees Information During fee calculation, if fee information is provided and stored in the GPP database as CDB fees, which are received from a financial institution’s system, GPP uses the provided fees for the specific Fee Types and does not calculate these fees. GPP only adds other fees if so defined and present in a transaction. Note: GPP applies fees only to a target account in an outgoing or incoming transaction. GPP does not support receiving fees from Account Lookup response on a source account in an outgoing transaction. 3.3.2.6 Request and Response Matching Upon receipt of a response from an external Account Lookup interface, GPP attempts to match the incoming response with the corresponding request that was previously transmitted. GPP performs matching using theand tags in addition to the transaction P_MID value to match the incoming response and transmitted request. GPP matching ensures the debit-side request is matched to the debit-side response, and the credit-side request is matched to the credit-side response. P_MID is mandatory for matching when the default GPP Bulk Interface functionality is implemented and interface messages are received by GPP in a bulk file with matching performed after the file is de-bulked. Note: GPP matching does not use an Event ID, which is not a mandatory tag in the Account Lookup interface response. 3.3.3 Manual Handling In various transaction processing scenarios, GPP might route a transaction to a manual handling queue after invoking the Account Lookup interface. Authorized GPP users can access transactions in these queues to determine additional transaction processing. GPP might route a transaction to a manual handling queue in the following scenarios: If GPP invokes an interface in asynchronous mode, GPP routes a transaction to a wait queue until receipt of a response from the interface. For more information, see Wait Queues. GPP PAYplus | System Integration - Files | Page 15 If an interface is inactive, GPP routes a transaction to an inactive queue until the interface becomes active. For more information, see Inactive Queues. In response to information received from an interface, GPP routes a transaction to a manual handling queue. For more information, see Manual Queues. Note: After an authorized user submits a transaction to continued processing from a manual or wait queue, GPP retrieves customer and account information from the MESSAGE_EXTERNAL_INTERACTION database table that was stored from a previously received Account Lookup request (if available). GPP uses the stored information for continued transaction processing. 3.3.3.1 Inactive Queues If an interface is inactive, GPP routes transactions that are waiting for transmission to the interface to an inactive queue. An authorized GPP user can access transactions in these queues types to perform manual actions on individual transactions. 3.3.3.1.1 Inactive CDB (CDBSTOP) Queue If the Account Lookup interface is inactive when GPP attempts to transmit a request, GPP routes the transaction to the Inactive CDB queue. A financial institution can determine continued transaction processing by defining the Non-active behavior field in the relevant Interfaces profile (see Interfaces Profile). While the Account Lookup interface is inactive, authorized users can access transactions in the Inactive CDB queue. From this queue, a user can only cancel a transaction. When canceling a transaction, GPP does one of the following: If stopped on the target account, GPP invokes a cancellation flow on the transaction. If stopped on the source account in the Consolidate mode, GPP invokes a cancellation flow on the S message and all its relevant I transactions. 3.3.3.2 Manual Queues GPP routes transactions that are waiting for manual user intervention to a manual queue for authorized user intervention. An authorized GPP user can access transactions in these queues to perform manual actions on individual transactions. 3.3.3.2.1 Posting Restrictions (POSTREST) Queue GPP can route a transaction, if stopped on the target account, or the related S message, if stopped on the source account in the Consolidate mode, to the Posting Restrictions queue after receiving a failure response from the Account Lookup interface with indication of posting restrictions. The response contains posting restrictions/limitations on the account or the customer and includes a predefined GPP Stop Flag as the reason for the failure. From this queue, an authorized user can do the following: Override: Instructs GPP to override the restriction if the response contains a Stop Flag that can be overridden. An override returns the transaction to the processing workflow. In all the relevant I transactions (single target account, if stopped on target account, or all I transactions related to the S, if stopped on source account), GPP sets the MU_STOP_FLAGS_OVERRIDE_STS to O, which indicates the posting restriction override. GPP uses this monitor and its value, when building, later in the flow, Balance Inquiry and Posting request, including this indication, or a more general one, to pass the information to the balance and accounting systems that a user decided to override the Stop Flag. Cancel: Instructs GPP to cancel the transaction, if stopped on the target account, or the S message and all its relevant I transactions, if stopped on the source account Note: Repair is not allowed in file handling flows and hence any other failures received in Account Lookup response will result in a rejection of the relevant transaction (if on target account) or S message with all its related I transactions. GPP PAYplus | System Integration - Files | Page 16 3.3.3.3 Wait Queues GPP routes transactions that are waiting for a response from an external interface or system in wait queues. An authorized GPP user can access transactions in these queues to perform manual actions on individual transactions. 3.3.3.3.1 Wait CDB Response (CDBWAIT) Queue When GPP invokes the Account Lookup interface for a target account in asynchronous mode, an individual transaction is stopped in the Wait CDB Response queue until a response is received from the external system. When GPP invokes the Account Lookup interface for a source account in synchronous mode, the process is not stopped but waits for an online response, and the transaction is not parked in a queue. From this queue, an authorized use can only cancel a transaction. When canceling a transaction, GPP does one of the following: If stopped on the target account, GPP invokes a cancellation flow on the transaction. If stopped on the source account in the Consolidate mode, GPP invokes a cancellation flow on the Sub Batch (S) message and all its relevant I transactions. 3.3.4 Business Setup and System Configuration GPP uses business setup and system configuration reference data to enable system operation, transaction processing, and UI functionality. 3.3.4.1 Business Setup GPP uses business reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining business rules, a financial institution can tailor system behavior to specific business requirements. 3.3.4.1.1 System Parameters The following table describes the business-related System Parameters, which authorized users can change, that GPP uses to implement the Account Lookup interface. Parameter Name Description ASAP_POST_REST_CHECK Specifies whether GPP performs the Stop Flags check as soon as possible. One of the following values: Yes: GPP initially performs the check on the debit and credit sides separately when the relevant account is loaded from GPP or a feeder request. GPP also performs an additional check for both sides later in the flow. No: GPP performs a consolidated check on the debit and credit sides later in the flow, after Method of Payment (MOP) Selection, STP Override, fee calculation, and Time Hold rules but before routing future-dated transactions to the Scheduled queue. 3.3.4.1.2 Profiles GPP uses profiles to determine how to process each transaction and payment-related message using the specific information associated with the transaction. 3.3.4.1.2.1 Accounts Profile If the financial institution requires keeping a profile representing an account in GPP, but still regards the Master account profile as the profile managed in the external system, the External Lookup GPP PAYplus | System Integration - Files | Page 17 checkbox should be selected in the GPP Accounts profile. GPP then invokes the Account Lookup interface for this account even though it has a GPP profile. 3.3.4.1.2.2 Stop Flags Profile The Stop Flags profile enables GPP to stop transaction processing upon receipt of a specific response from an interface. It is required if an Account Lookup interface response might include a Stop Flag or limitation on an account or customer. GPP must have a defined Stop Flag profile for all possible values that can be returned by the Account Lookup interface. GPP uses the Override checkbox in the profile to determine possible user actions in the Posting Restrictions queue. 3.3.4.1.3 Rules At various points during the transaction processing workflow, GPP invokes rules to determine continued transaction processing and handling. 3.3.4.1.3.1 Account Lookup Rules Rules should be set to invoke the Account Lookup interface for a debit or credit account if they belong to a customer (relevant side MOP is BOOK), and the master copy of the account is not managed in GPP, as per specific FI business scenarios and conditions. Note: These rules are invoked whenever a debit or credit account of a transaction 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.3.4.1.3.2 Credit Account Enrichment Rule This rule provides a dummy account as credit account to an outgoing credit transfer transaction that is On-Us during the Pre-Processing Transactions flow to enable GPP to skip the Account Lookup interface on the target account during Pre-Processing Transactions and invoke it during Execution. 3.3.4.1.3.3 Debit Account Enrichment Rule This rule provides a dummy account as debit account to an outgoing direct debit transaction during the Pre-Processing Transactions flow to enable GPP to skip the Account Lookup interface on the target account during Pre-Processing Transactions and invoke it during Execution. 3.3.4.2 Permissions All prerequisite permissions must be defined for users who will access profiles and business rules that are related to the Account Lookup interface. 3.3.4.3 System Configuration GPP uses system reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining system reference data, GPP can tailor system behavior to specific financial institution requirements. Note: GPP supplies a full set of system reference data that are customized to specific financial institution requirements. In most cases, authorized GPP users can view, but not update, system reference data. 3.3.4.3.1 System Parameters The Account Lookup interface requires no specific system parameters. 3.3.4.3.2 Profiles GPP uses profiles to determine how to process each transaction and payment-related message using the specific information associated with the transaction. 3.3.4.3.2.1 Interfaces Profile GPP PAYplus | System Integration - Files | Page 18 The Interfaces profile stores definitions about how GPP interacts and communicates with external systems. The GPP Account Lookup interface requires relevant Interfaces profiles, which should be configured for the Account Lookup interface. It is usually required to set separate debit- and credit-side entries for the debit side and for the credit side). The timeout, when relevant, 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. GPP recommends that the Account Lookup interface Non-active behavior is setup as STOP_UNTIL_ACTIVE with the Inactive queue as Inactive CDB (CDBSTOP). GPP uses the Non-active behavior field to determine continued transaction processing if a transaction is inactive. The field can have one of the following values: PERMANENT_STOP: If the interface is inactive, GPP stops transaction processing and routes the transaction to the Inactive CDB queue. GPP does not continue processing the transaction after the interface becomes active. STOP_UNTIL_ACTIVE: If the interface is inactive, GPP stops transaction processing and routes the transaction to the Inactive CDB queue. GPP continues processing the transaction when the interface becomes active. Note: These are relevant only for Account Lookup requests during the Execution stage and not for requests sent during Pre-Processing Transactions when the file rolled functionality is used. For a description of the relevant fields, see the GPP Online Help or the GPP Interfaces Technical Guide. Note: When GPP is defined to use the Fndt Message format structure for a specific interface type, GPP can also be set up to define which sections of the structure to send. This definition can be a maximum with a full structure (including all the message related attributes), to a minimum that is specific per interface type. For example for Account Lookup interface only the sections quoting details of the account, customer and contacts. 3.3.4.3.3 Rules At various points during the transaction processing workflow, GPP invokes business rules to determine continued transaction processing and handling. 3.3.4.3.3.1 Interface Selection Rule The GPP Account Lookup interface requires Interface Selection rules, which GPP invokes to determine the most appropriate Interfaces profile for each transaction. 3.3.5 Message Data The Account Lookup interface requires no specific message attributes, errors, or Audit Trail entries. 3.4 Balance Inquiry Interface 3.4.1 Overview GPP invokes the Balance Inquiry interface to determine whether the debit account of a transaction has sufficient funds to execute a transaction. During transaction processing, GPP invokes the Balance Inquiry interface to generate a request to an external host system, in which a financial institution manages the debit account of the transaction. The request contains, among other information, the amount of the transaction and debit account identification information. The Balance Inquiry interface can generate and transmit one of the following requests types: GPP PAYplus | System Integration - Files | Page 19 Balance Check: To determine whether the debit account contains sufficient funds to execute a transaction or a sub-batch of transactions. For more information, see Balance Check Workflow. Balance Check with Balance Reservation: To determine whether the debit account contains sufficient funds to execute a transaction or a sub-batch of transactions. In addition, the request includes an optional Balance Reservation indicator, which instructs the host system to reserve, or earmark, funds in the debit account equal to the amount of a transaction or a sub-batch of transactions. GPP can invoke the Balance Inquiry in a Consolidated mode, which transmits single requests, or Individual mode, which transmits requests in bulk. For more information, see Balance Inquiry Modes and Interface Transmission Modes. The host system receives and processes the request and then returns a response to GPP. The response contains an indicator that GPP uses to determine whether to execute the transaction. The host system is responsible for the following: Account Balance Evaluation: The host system evaluates whether the debit account contains sufficient funds to execute a transaction or a sub-batch of transactions. The evaluation can include the account’s net balance, credit lines, and limits. It might also take into account the balance of a group of accounts. Funds Reservation: If supported by the host system and explicitly indicated in the request, a host system can reserve, or earmark, an amount in the debit account equal to a transaction or a sub-batch of transactions. If successful, the host system returns a positive response that includes a Balance Reservation reference number. The Balance Inquiry interface supports the standard Fndt request and response message format. For more information, see the GPP Fndt Message Usage for Balance Inquiry Interface Technical Guide. GPP can also support proprietary formats to meet specific financial institution business requirements. Proprietary format support might require additional mapping and is dependent on the presence of message attributes required by GPP. For information about the types of responses that the Balance Inquiry interface can receive from the host system, see Balance Check Response. This interface includes a Balance Reservation Release interface, which releases funds that were reserved by a previously transmitted Balance Check request.. For more information, see Balance Reservation Release InterfaceError! Reference source not found.. 3.4.2 Processing GPP transaction processing includes both generic workflows and workflows dedicated to specific functionality and transaction types. 3.4.2.1 Balance Check Workflow The following shows the Balance Check workflow that generates and sends a request to a host system to check the balance of a debit account. The workflow also handles the response received from the host system. GPP PAYplus | System Integration - Files | Page 20 3.4.2.2 Balance Check Details Upon receipt of a file containing one or more transactions from a clearing system, financial institution, or other channel, GPP begins processing each transaction and payment-related message in the file using the standard processing workflow for each type of transaction. GPP invokes Interface Selection system rules to determine whether to invoke the Balance Inquiry interface. GPP configuration invokes the Balance Inquiry interface in an asynchronous mode, in which GPP sends a request to the interface and routes the transaction to the BI Wait queue until receipt of a corresponding response. During the Analysis stage of the processing workflow, GPP invokes BI_Bypass business rules to determine whether to invoke or to bypass the interface. If configured to bypass the interface, GPP continues with the generic transaction or sub-batch processing workflow. For more information, see BI_Bypass Rules. GPP PAYplus | System Integration - Files | Page 21 If GPP determines that a transaction (or a sub-batch of transactions) requires a balance check, GPP invokes the Balance Inquiry interface to generate and transmit a request to the host system. 3.4.2.2.1 Balance Inquiry Modes During processing, GPP invokes the Balance Inquiry in either of the following modes: Consolidated: GPP generates a single request for the consolidated (total) amount of all relevant transactions in each sub-batch in the file. Upon receipt of a mass payment file, GPP generates a consolidated S message for all transactions in the sub-batch and transmits a Balance Inquiry request for the consolidated amount. Individual: GPP invokes the interface for each transaction. Upon receipt of a mass payment file, GPP implements the generic transaction processing workflow and invokes the Balance Inquiry interface for each transaction. The interface generates a request for each transaction, which GPP transmits as a bulk file via the Bulk Interface. The bulk file includes a header for file identification. The body of the file contains a specific tag for each occurrence of the individual request, each in the standard Fndt message structure. For more information about the Bulk interface, see Bulk Interface. If configured to do so, GPP generates all interface requests in the standard Fndt message structure. For more information, see the GPP Fndt Message Usage for Balance Inquiry Technical Guide. 3.4.2.2.2 Balance Check Request The Balance Inquiry interface generates and transmits a Balance Check request to the host system to determine whether the debit account has sufficient funds to execute a transaction. The request can include an optional Balance Reservation indicator that instructs the host system to reserve (earmark) an amount equal to the transaction amount. GPP can generate and transmit a request for an entire file or for individual transactions depending on the configured mode, as described in Interface Transmission Modes. The type of Balance Inquiry request generated depends on interface configuration. For more information, see Balance Inquiry Modes. Each request includes a unique, 16-character Event ID as an identifier. If resending a request, GPP transmits the request with the original Event ID. Note: If using the GPP Standard Balance Inquiry format, this identifier is set in the Event ID tag of the request’s header section. GPP stores the Event ID in the EVENT_ID column of the Message External Interaction table for interfaces that are configured to create a MESSAGE_EXTERNAL_INTERACTION entry and the EVENT_ID_GENERATION field is set to 1 in the INTERFACE_TYPES entry. GPP generates the identifier using the MID generation algorithm. The Event ID can also be used in the D_MEI_EVENT_ID logical field. After generating a Balance Check request, GPP transmits it to the host system, which returns a response, as described in Balance Check Response. If configured to work asynchronous mode, after transmitting the request, GPP does one of the following: Consolidated Mode: Sets the S message with a BIWAITQ status and routes it to the Wait Balance Inq. Response queue to wait for a response from the host system. GPP also sets all individual transactions that are associated with the S message with a WAITSUBBATCH status and routes each to the Wait Sub-Batch queue. Individual Mode: Sets the transaction with a BIWAITQ status and routes it to the Wait Balance Inq. Response queue to wait for a response from the host system. GPP PAYplus | System Integration - Files | Page 22 3.4.2.2.3 Balance Check Response Upon receipt of a Balance Inquiry interface request, the host system determines whether the debit account contains sufficient funds to execute the transaction and returns a response to GPP. If configured for Bulk mode (see Interface Transmission Modes), the response file contains a structured header and one or more responses to the previously transmitted requests. GPP parses the incoming file and does the following for each response: 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. Attempts to match the response to its corresponding request, as described in Response and Request Matching. Stores the response in the Processing Communications field in the MESSAGE_EXTERNAL_INTERACTION table, if configured to do so. Generates an Audit Trail entry to indicate the receipt of a response. For more information, see Audit Trail Entries. Generates an Error Log entry if the incoming response is negative. The Error Log entry includes an error description. Evaluates the response to determine continued transaction processing for each of the following response types: - Success: Indicates that the account contains sufficient funds to execute the transaction. For more information, see Successful Response. - Failure: Indicates that the account does not contain sufficient funds to execute the transaction. For more information, see Failure Response. - Functional Error: Indicates an error occurred in the host system. For more information, see Functional Error Response. If GPP does not receive a response within a configurable timeout period when transmitting a request using a single interface, GPP resends the request until it meets the number of retry times defined in the relevant Interfaces profile. If GPP does not receive a response after the defined number of retries, the interface becomes inactive and GPP handles the request as a Functional Error response. 3.4.2.2.3.1 Successful Response A successful Balance Check response indicates that the debit account has sufficient funds to execute the transaction. Upon receipt of a successful response, GPP does the following: Stores any additional information included in the response in the transaction data Routes the transaction to the transaction processing workflow for continued processing Sets the MI_BI_STS column to P Note: If the request included a Balance Reservation indicator and the response included a Balance Reservation Reference, GPP returns the indicator to the host system during posting. 3.4.2.2.3.2 Failure Response A failure Balance Check response indicates that the debit account does not have sufficient funds to execute the transaction. A failure response can indicate the following: GPP PAYplus | System Integration - Files | Page 23 The debit account does not have sufficient funds to execute the transaction. Upon response receipt, GPP matches the response to the corresponding request and does one of the following: - Consolidation Mode: GPP sets the S message with an NSF status, routes it to the Insufficient Funds queue, and invokes the automatic retry mechanism, as described in Automatic Retry Mechanism. GPP also sets all individual transactions that are associated with the S message with a WAITSUBBATCH status and routes each to the Wait Sub-Batch queue. - Individual Mode: GPP sets the transaction with an NSF status, routes it to the Insufficient Funds queue, and invokes the automatic retry functionality. For any type of failure response, GPP sets the MI_BI_STS column to N. An authorized GPP user can access transactions in the Insufficient Funds queue to perform manual actions on individual transactions. For more information, see Insufficient Funds (NSF) Queue. 3.4.2.2.3.3 Functional Error Response A functional error Balance Check response indicates that a functional error has occurred, such as the debit account does not exist in the host system. To indicate a functional error, the host system returns a response that includes an error code and error description. Upon receipt of the response, GPP does the following: Routes the transaction to the Rejected (REJECTED) queue as a final status Sets the MI_BI_STS column to N 3.4.2.3 Balance Reservation Release Interface GPP invokes the Balance Reservation Release interface to release funds that were reserved (earmarked) by a previously transmitted Balance Check request that included the Balance Reservation indicator. This interface generates a request to the financial institution’s host system that instructs the host system to release any funds reserved by a previous Balance Check request. GPP invokes the Balance Reservation Release interface from the cancellation flow to handle the following post-dated credit transfers: If a consolidated S message is cancelled from the Scheduled queue, GPP cancels all associated I messages. If one or more transactions are cancelled that were part of a consolidated S message in the Scheduled queue, GPP cancels the relevant I messages and updates the amount of the consolidated S message. After receipt a successful response (see Successful Response) but prior to transaction posting, the Balance Reservation Release functionality invokes the Balance Reservation Release interface, which transmits a Balance Reservation Release request. The request includes the Balance Reservation Reference returned by the host system in the response to the original request. The Balance Reservation Release request instructs the host system to release any funds that it has reserved in response to the original Balance Check request. Note: The Balance Reservation Release interface operates in a Single mode only. For more information, see Interface Transmission Modes. After receipt of a response from a Balance Check request, GPP does not invoke the Balance Reservation Release functionality after the following: Receipt of a failure or functional error response Receipt of a successful response that did not include a Balance Reservation Reference GPP PAYplus | System Integration - Files | Page 24 3.4.2.3.1 Balance Reservation Release Request GPP sends a Balance Reservation Release request to instruct the host system to release any funds that it has reserved in response to a Balance Check request. The request includes the Balance Reservation Reference returned by the host system in the response to the original request. GPP populates the Balance Reservation Reference field from the P_BI_MAIN_ERAMARK_REF or P_BI_FEE_ERAMARK_REF field, depending on the type of amount reserved. If configured to use the Standard Fndt Message format, GPP populates the field from the value stored in F_BI_INFO_EARMARK_REF. In addition to the Balance Reservation Reference, the Balance Reservation Release request contains a new Event ID. After transmitting the Balance Reservation Release request, GPP does not route the transaction to a wait queue. 3.4.2.3.2 Balance Reservation Release Response In response to a Balance Reservation Release request, the host system returns a response to GPP. Upon receipt of the response, GPP does the following: Parses the response. 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. Attempts to match the response to its corresponding request, as described in Response and Request Matching. Stores the response in the Processing Communications field in the MESSAGE_EXTERNAL_INTERACTION table, if configured to do so. Generates an Audit Trail entry to indicate the receipt of a response. For more information, see Audit Trail Entries. Note: If the incoming response is negative, GPP sets a follow-up flag with NEG_BI_RSPNS_AFTR_RLS value for the transaction. A Custom Filter rule can be defined to enable authorized users to access the transaction in a custom queue. 3.4.2.4 Automatic Retry Mechanism As part of the Balance Inquiry interface functionality, GPP implements an automatic retry mechanism for transactions with an NSF status. If a host interface returns a failure response that indicates the debit account does not have sufficient funds to execute a transaction, GPP sets the transaction with an NSF status and routes it the Insufficient Funds queue. The automatic retry mechanism periodically checks each transaction in the queue for possible updates to the transaction’s debit account by repeatedly invoking the Balance Inquiry interface and does one of the following: If GPP determines that the debit account balance is equal to or greater than the transaction amount, GPP releases the transaction into the transaction processing workflow for continued processing. If GPP determines that the debit account balance is less than the transaction amount, GPP continues to hold the transaction in the Insufficient Funds queue. The automatic retry mechanism uses a time period (defined in the NSF_CHECK_FREQ parameter) to determine the frequency with which the mechanism invokes the Balance Inquiry interface. The mechanism also uses the maximum number of retries (defined in the MAXNSFRETRY parameter) for each transaction. After the mechanism has reached the defined maximum number of GPP PAYplus | System Integration - Files | Page 25 retries for a specific transaction, the mechanism stops retrying to check the balance of the transaction and holds it in the Insufficient Funds queue for manual handling. For more information about parameters, see System Parameters. GPP enables an authorized user to manually retry to check the balance of a transaction. For more information, see Manual Queues. Transactions that are not manually processed remain in the Insufficient Funds queue. Note: NSF is not a final status. GPP recommends clearing transactions from the Insufficient Funds queue at the end of each business day. 3.4.2.5 Response and Request Matching Upon receipt of a response from an external Balance Inquiry interface, GPP attempts to match the incoming response with the corresponding request that was previously transmitted. GPP performs matching using the and tags in addition to the transaction P_MID value to match the incoming response and transmitted request. P_MID is mandatory for matching when the default GPP Bulk Interface functionality is implemented and interface messages are received by GPP in a bulk file with matching performed after the file is de-bulked. Note: GPP matching does not use an Event ID, which is not a mandatory tag in the Balance Inquiry interface response. 3.4.3 Manual Handling In various transaction processing scenarios, GPP might route a transaction to a manual handling queue after invoking the Balance Inquiry interface. Authorized GPP users can access transactions in these queues to determine additional transaction processing. GPP might route a transaction to a manual handling queue in the following scenarios: If GPP invokes the interface in asynchronous mode, GPP routes each transaction to a wait queue until receipt of a response from the interface. For more information, see Wait Queues. If the interface is inactive, GPP routes each transaction to an inactive queue until the interface becomes active. For more information, see Inactive Queues. In response to information received from the interface, GPP might route each transaction to a manual handling queue. For more information, see Manual Queues. 3.4.3.1 Inactive Queues If the interface is inactive, GPP routes each transaction that is waiting for transmission to the interface to an inactive queue. An authorized GPP user can access transactions in these queue types to perform manual actions on individual transactions. 3.4.3.1.1 Inactive BI (BI_STOP) Queue If the Balance Inquiry interface is inactive when GPP attempts to transmit a request, GPP routes the transaction to the Inactive BI queue. A financial institution can determine continued transaction processing by defining the Non-active behavior field in the relevant Interfaces profile (see Interfaces Profile). Cancelling a transaction is the only manual action enabled from the Inactive BI queue. GPP PAYplus | System Integration - Files | Page 26 3.4.3.2 Manual Queues GPP routes transactions that are waiting for manual user intervention to a manual queue for authorized user intervention. An authorized GPP user can access transactions in these queues to perform manual actions on individual transactions. 3.4.3.2.1 Insufficient Funds (NSF) Queue If the Balance Inquiry interface determines that the transaction’s debit account does not have sufficient funds to execute the transaction, GPP routes the transaction to the Insufficient Funds queue. While holding a transaction in this queue, GPP implements an automatic retry mechanism on the transaction. For more information, see Automatic Retry Mechanism. An authorized user can access each transaction in the queue and do one of the following: Force Ins. Funds: Instructs GPP to continue processing a transaction that has insufficient funds. Only an authorized user whose user profile has a defined maximum force limit amount that is greater than the transaction amount can perform this action. The Balance Inquiry interface generates another request with a new Event ID to the host system. The request includes additional information indicating the user decision to continue processing the transaction with insufficient funds. If using the Standard Fndt Message, the MU_NSF_FORCE_STS field is set to 1 in Monitors extension. If sending a request with a Balance Reservation, after transmitting the request, GPP continues processing the transaction without a Balance Reservation indicator. Retry Ins. Funds: Instructs GPP to invoke the Balance Inquiry interface again. GPP submits the transaction back to the transaction processing workflow and the Balance Inquiry interface, which generates an additional request with a new Event ID. After transmitting the request, GPP routes the transaction to the Wait Balance Inq. queue pending a response from the host system. Cancel: Instructs GPP to cancel the transaction. GPP routes the transaction to the cancellation flow, including Balance Reservation Release and reverse posting, if required. If a user cancels an individual transaction in Consolidated mode (see Balance Inquiry Modes), GPP cancels only that transaction and reduces the amount of the corresponding S message by the amount of the canceled transaction. 3.4.3.3 Wait Queues GPP routes transactions that are waiting for a response from an external interface or system in wait queues. An authorized GPP user can access transactions in these queues to perform manual actions on individual transactions. 3.4.3.3.1 Wait Balance Inq. (BIWAITQ) Queue After transmitting an asynchronous Balance Inquiry interface request to a host system, GPP routes the transaction to the Wait Balance Inq. Response queue until receipt of a response from the host system. Note: After transmitting a synchronous Balance Inquiry request, GPP waits for an online response but does not route the transaction to any specific queue. 3.4.4 Business Setup and System Configuration GPP uses business setup and system configuration reference data to enable system operation, transaction processing, and UI functionality. GPP PAYplus | System Integration - Files | Page 27 3.4.4.1 Business Setup GPP uses business reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining business rules, a financial institution can tailor system behavior to specific business requirements. 3.4.4.1.1 System Parameters The following table describes the business-related System Parameters, which authorized users can change, that GPP uses to implement the Balance Inquiry interface. Parameter Name Description MAXNSFRETRY The maximum number of times that GPP checks whether the debit account balance of a transaction is equal to or greater than the transaction amount. The default value is five. NSF_CHECK_FREQ The frequency (in milliseconds) that GPP checks the debit account balance of each transaction in the Insufficient Funds queue to determine whether the balance is equal to or greater than the transaction amount. The default value is 300,000 (five minutes). 3.4.4.1.2 Profiles GPP uses profiles to determine how the system processes each transaction and payment-related message using the specific information associated with the transaction. 3.4.4.1.2.1 User Codes Profile This profile stores codes that GPP accesses during various transaction processing workflows. The following table lists the user code required by the Balance Inquiry interface. Type Code Description FOLLOWUP NEG_BI_RSPNS_AFTR_RLS GPP received a negative response on Balance Reservation Release during transaction cancellation. 3.4.4.1.3 Rules At various points during the transaction processing workflow, GPP invokes business rules to determine continued transaction processing and handling. 3.4.4.1.3.1 BI_Bypass Rules BI_Bypass rules enable a financial institution to define conditions that, when met, prevent GPP from invoking the Balance Inquiry interface. When invoking the Balance Inquiry interface in Consolidated mode (see Balance Inquiry Modes), this rule prevents GPP from invoking the interface at the file level. 3.4.4.2 Permissions All prerequisite permissions must be defined for users who will access profiles and business rules that are related to the Balance Inquiry interface. GPP PAYplus | System Integration - Files | Page 28 3.4.4.3 System Configuration GPP uses system reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining system reference data, GPP can tailor system behavior to specific financial institution requirements. Note: GPP supplies a full set of system reference data that are customized to specific financial institution requirements. In most cases, authorized GPP users can view, but not update, system reference data. 3.4.4.3.1 System Parameters The Balance Inquiry interface requires no specific system parameters. 3.4.4.3.2 Profiles GPP uses system profiles to determine how the system processes each transaction and paymentrelated message using the specific information associated with the transaction. 3.4.4.3.2.1 Event Profiles Event profiles enable GPP to manage and handle specific events that might occur during transaction processing. The following table describes an insufficient funds event required by the Balance Inquiry interface. Name Mode Minutes Batch Size Description NSF 0 10 1 Automatic retry for NSF transactions For more information about Event profiles, see the GPP Online Help. 3.4.4.3.2.2 Interfaces Profile The Interfaces profile stores definitions about how GPP interacts and communicates with external systems. GPP uses the Non-active behavior field to determine continued transaction processing if a transaction is inactive. The field can have one of the following values: PERMANENT_STOP: If the interface is inactive, GPP routes the transaction to the Inactive BI queue and stops transaction processing. GPP does not continue processing the transaction after the interface becomes active. While the interface is inactive, authorized users can access transactions in the Inactive BI queue (see Inactive BI (BI_STOP) Queue). SKIP: If the interface is inactive, GPP does not invoke the interface and continues transaction processing. STOP_UNTIL_ACTIVE: If the interface is inactive, GPP routes the transaction to the Inactive BI queue and stops transaction processing. GPP continues processing the transaction when the interface becomes active. While the interface is inactive, authorized users can access transactions in the Inactive BI queue. For more information about Interfaces profiles, see the GPP Online Help. 3.4.4.3.3 Rules At various points during the transaction processing workflow, GPP invokes system rules to determine continued transaction processing and handling. GPP PAYplus | System Integration - Files | Page 29 3.4.4.3.3.1 Interface Selection Rules The Balance Inquiry interface requires Interface Selection rules, which GPP invokes to determine the most appropriate Interfaces profile for each transaction, flow, and invocation point. 3.4.5 Message Data The Balance Inquiry Interface requires no specific message attributes. 3.4.5.1 Audit Trail Entries GPP generates an Audit Trail entry for each transaction and Return message if a user performs a manual action on it in any of the related manual and wait queues. 3.4.5.2 Error Codes The Balance Inquiry interface requires no specific error codes. 3.5 Compliance Interface 3.5.1 Overview The GPP Compliance Interface enables a financial institution to comply with various laws, rules, and regulations enacted by some countries and government organizations to prevent terror financing and money laundering. The interface enables these organizations, such as the United States Office of Foreign Assets Control (OFAC), to enforce economic and trade sanctions on relevant parties during transaction processing. The Compliance Interface enables a financial institution to verify that all incoming and outgoing transactions comply with all relevant laws and regulations. The interface communicates with an external financial institution compliance system to determine whether a transaction is in compliance with all relevant rules and regulations. It is an asynchronous process that enables GPP to generate an outgoing request to an external system, which validates a transaction for compliance. GPP can also receive and process the incoming responses returned by the external interface. The Compliance Interface supports the standard Fndt request and response message format. For more information, see the GPP Fndt Message Usage for Compliance Interface Technical Guide. GPP can also support proprietary formats to meet specific financial institution business requirements. Proprietary format support might require additional mapping and is dependent on the presence of message attributes required by GPP. The GPP default configuration transmits Compliance interface requests and receives responses in the Bulk mode. For more information, see Interface Transmission Modes. 3.5.2 Processing A financial institution can determine which transactions require compliance validation by defining business rules to bypass or invoke the Compliance Interface for specific transaction types. For more information, see Compliance Validation Rules. 3.5.2.1 Workflow The following shows the Compliance Interface workflow. GPP PAYplus | System Integration - Files | Page 30 3.5.2.2 Details GPP invokes the Compliance logic during individual transaction processing as follows: Itemized: GPP invokes the interface separately on each I message during Sub-batch Completion before I message posting. Consolidated: GPP invokes the interface separately on each I message during Sub-batch Completion before I message posting and after S message posting. At the specific point, GPP invokes Compliance Validation business rules (see Compliance Validation Rules) to determine whether to invoke the Compliance Interface as follows: If GPP determines that a transaction meets a rule’s criteria and the rule’s Action field is set to SANCTIONS, GPP invokes the Compliance Interface and does the following: - Generates and transmits an interface request in the relevant format - Sets the transaction status to WAITCOMPLIANCECHECK - Routes the transaction to the Wait Compliance Check queue to wait for an interface response GPP PAYplus | System Integration - Files | Page 31 Note: An authorized GPP user can also access transactions in the Wait Compliance Check queue to perform manual actions before receipt of an interface response for the transaction. For more information, see Wait Compliance Check Queue (WAITCOMPLIANCECHECK). If GPP determines that a transaction meets a rule’s criteria and the rule’s Action field is set to BYPASS, GPP does not invoke the Compliance Interface and continues with the generic transaction processing workflow. Note: As part of the GPP release, a default rule should be provided as per a financial institution's requirement. If, for some reason, no rule is defined, GPP sets the transaction with a Repair (REPAIR) status, generates a 40142 error code (see Error Codes), and routes the transaction to the Repair queue for manual handling. After invoking the interface, GPP holds each transaction in the Wait Compliance Check queue until receipt of a matching response (see Response and Request Matching). GPP uses the return code in the response to determine continued transaction processing and handling. A response can contain one of the following return codes: Hit: One or more transaction attributes matched a value in a compliance list, which generates a Hit response. GPP does the following: - Sets the transaction status to COMPEX - Routes the transaction to the Compliance Exception queue for manual handling (see Compliance Exception Queue (COMPEX)) Hit and Seize: One or more transaction attributes matched a value in a compliance list, which generates a Hit and Seize response. GPP does the following: - Populates the transaction’s credit account with the defined Seized Funds Account field in the relevant Currencies Preferences profile (see Currencies Preferences Profile). - Sets the MOP to BOOK. - Routes the transaction to the Sub-batch Completion flow, during which GPP invokes Credit Account Enrichment rules (see Credit Account Enrichment Rules). A financial institution can define these rules to override, if required, the credit account taken from the Currencies Preferences profile. - Sets the transaction status to SEIZED and processes the transaction to the final status Seized queue. No Hit: No transaction attributes matched any value in a compliance list, which generates a No Hit response. GPP routes the transaction to the generic transaction processing workflow. If GPP does not receive a response within a configurable timeout period, GPP resends the request until it meets the number of retry times defined in the relevant Interfaces profile. If GPP does not receive a response after the defined number of retries, the interface becomes inactive and GPP handles the compliance request as Failed. 3.5.2.3 Response and Request Matching Upon receipt of a response from an external Compliance interface, GPP attempts to match the incoming response with the corresponding request that was previously transmitted. GPP performs matching using the and tags in addition to the transaction P_MID value to match the incoming response and transmitted request. P_MID is mandatory for matching when the default GPP Bulk Interface functionality is implemented and interface messages are received by GPP in a bulk file with matching performed after the file is de-bulked. Note: GPP matching does not use an Event ID, which is not a mandatory tag in the Compliance interface response. GPP PAYplus | System Integration - Files | Page 32 3.5.3 Manual Handling In various transaction processing scenarios, GPP might route a transaction to a manual handling queue after invoking the Compliance interface. Authorized GPP users can access transactions in these queues to determine additional transaction processing. GPP might route a transaction to a manual handling queue in the following scenarios: If GPP invokes an interface in asynchronous mode, GPP routes a transaction to a wait queue until receipt of a response from the interface. For more information, see Wait Queues. If an interface is inactive, GPP routes a transaction to an inactive queue until the interface becomes active. For more information, see Inactive Queues. In response to information received from an interface, GPP routes a transaction to a manual handling queue. For more information, see Manual Queues. 3.5.3.1 Inactive Queues If an interface is inactive, GPP routes transactions that are waiting for transmission to the interface to an inactive queue. An authorized GPP user can access transactions in these queues types to perform manual actions on individual transactions. 3.5.3.1.1 Compliance Inactive (COMPLIANCE_INACTIVE) Queue If the Compliance interface is inactive when GPP attempts to transmit a request, GPP routes the transaction to the Compliance Inactive queue. A financial institution can determine continued transaction processing by defining the Non-active behavior field in the relevant Interfaces profile (see Interfaces Profile). While the interface is inactive, authorized users can access transactions in the Compliance Inactive queue. From the Compliance Inactive queue, a user can only cancel a transaction. 3.5.3.2 Manual Queues GPP routes transactions that are waiting for manual user intervention to a manual queue for authorized user intervention. An authorized GPP user can access transactions in these queues to perform manual actions on individual transactions. 3.5.3.2.1 Approve Cancel Queue (APPROVE_CANCEL) If an authorized GPP user accesses a transaction or a Return message in the Wait Compliance Check queue or in the Compliance Exception queue and clicks Cancel, GPP routes the transaction or the Return message to the Approve Cancel queue for manual handling. An authorized user must access each transaction or Return message in this queue and click one of the following: Approve: Instructs GPP to approve the previous Cancel action. GPP routes the transaction or Return message to the cancellation flow, which includes reverse posting, if required. Refuse: Instructs GPP to refuse the previous Cancel action (from the Compliance Exception queue or from the Wait Compliance Check queue) and GPP routes transaction or Return message back to the queue from which it came. 3.5.3.2.2 Compliance Exception Approve (APPROVE_COMPEX) Queue If an authorized GPP user accesses a transaction or a Return message in the Compliance Exception queue or the Wait Compliance Check queue and clicks Block or Confirm, GPP routes the transaction or the Return message to the Compliance Exception Approve queue for manual handling. An authorized user must access each transaction or Return message in this queue and click one of the following: GPP PAYplus | System Integration - Files | Page 33 Approve: Instructs GPP to approve the previous manual action and one of the following occurs: - If the previous user performed a Confirm action from the Wait Compliance Check queue or Compliance Exception queue, GPP routes the transaction or the Return message to the Subbatch Completion flow to continue transaction processing as if a No Hit response was received. GPP does not invoke the Compliance Interface again. - If the previous user performed a Block action from the Wait Compliance Check queue or Compliance Exception queue, GPP does the following: › Sets MOP to BOOK › Populates the credit account with the defined Seized Funds Account field in the Currencies Preferences profile (see Currencies Preferences Profile) - Routes the transaction or the Return message to the Sub-batch Completion flow, during which GPP invokes Credit Account Enrichment rules (see Credit Account Enrichment Rules). A financial institution can define these rules to override, if required, the credit account taken from the Currencies Preferences profile. - Sets the status of the transaction or Return message to SEIZED and processes it to the final status Seized queue. Refuse: Instructs GPP to refuse the previous action and one of the following occurs: - If the previous user performed a Confirm or a Block action from the Wait Compliance Check queue, GPP routes the transaction or the Return message back to Wait Compliance Check to wait for a response from the Compliance Interface. - If the previous user performed a Confirm or a Block action from the Compliance Exception queue, GPP routes the transaction or the Return message back to the Compliance Exception queue for additional manual handling. 3.5.3.2.3 Compliance Exception Queue (COMPEX) If a transaction or Return message receives a Hit response from the Compliance Interface, GPP routes the transaction to the Compliance Exception queue. GPP uses the type of transaction to determine the types of manual actions available to an authorized user, as follows: For an incoming credit transfer, an authorized user can click one of the following: - Block: Instructs GPP to block the transaction and seize the funds. GPP routes the transaction to the Compliance Exception Approve queue for additional manual handling. - Confirm: Instructs GPP to confirms the transaction as compliant and disregards the Hit response. GPP routes the transaction to the Compliance Exception Approve queue for additional manual handling. - Reject/Return: Instructs GPP to return the transaction by generating a Return message. GPP opens the Message page to enable the user to create an outgoing Return message. Upon completion, GPP routes the original transaction to the Returned queue. For an outgoing credit transfer or an outgoing Return message, an authorized user can click one of the following: - Block: Instructs GPP to block the transaction or the Return message and seize the funds. GPP routes the transaction or the Return message to the Compliance Exception Approve queue for additional manual handling. - Cancel: Instructs GPP to cancel the transaction or the Return message. GPP routes transaction or the Return message to the Approve Cancel queue for additional manual handling. - Confirm: Instructs GPP to confirm the transaction as compliant and disregards the Hit response. GPP routes the transaction or the Return message to the Compliance Exception Approve queue for additional manual handling. GPP PAYplus | System Integration - Files | Page 34 For an incoming Return message, an authorized user can click one of the following: - Block: Instructs GPP to block the Return message and seize the funds. GPP routes the Return message to the Compliance Exception Approve queue for additional manual handling. - Confirm: Instructs GPP to confirm the transaction as compliant and disregard the Hit response. GPP routes the Return message to the Compliance Exception Approve queue for additional manual handling. 3.5.3.3 Wait Queues GPP routes transactions that are waiting for a response from an external interface or system in wait queues. An authorized GPP user can access transactions in these queues to perform manual actions on individual transactions. 3.5.3.3.1 Wait Compliance Check Queue (WAITCOMPLIANCECHECK) GPP holds transactions and Return messages in the Wait Compliance Check queue until receipt of a response from the Compliance Interface. Until receipt of a response, an authorized user can access a transaction or a Return message in this queue for manual handling as determined by the transaction or message type, as follows: For an incoming credit transfer, an authorized user can click one of the following: - Block: Instructs GPP to block the transaction and seize the funds. GPP routes the transaction to the Compliance Exception Approve queue for additional manual handling. - Confirm: Instructs GPP to confirm the transaction. GPP routes the transaction to the Compliance Exception Approve queue for additional manual handling. - Reject/Return: Instructs GPP to return the transaction by generating a Return message. GPP opens the Transaction page to enable the user to create an outgoing Return message. Upon completion, GPP routes the original transaction to the Returned queue. For an outgoing credit transfer or an outgoing Return message, an authorized user can click one of the following: - Block: Instructs GPP to block the transaction and seize the transaction funds. GPP routes the transaction to the Compliance Exception Approve queue for additional manual handling. - Cancel: Instructs GPP to cancel the transaction. GPP routes transaction to the Approve Cancel queue for additional manual handling. - Confirm: Instructs GPP to confirm the transaction as compliant and disregard the Hit response. GPP routes the Return message to the Compliance Exception Approve queue for additional manual handling. For an incoming Return message, an authorized user can click one of the following: - Block: Instructs GPP to block the transaction and seize the transaction funds. GPP routes the transaction to the Compliance Exception Approve queue for additional manual handling. - Confirm: Instructs GPP to confirm the transaction as compliant and disregard the Hit response. GPP routes the Return message to the Compliance Exception Approve queue for additional manual handling. 3.5.4 Business Setup and System Configuration GPP uses business setup and system configuration reference data to enable system operation, transaction processing, and UI functionality. 3.5.4.1 Business Setup GPP uses business reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining business rules, a financial institution can tailor system behavior to specific business requirements. GPP PAYplus | System Integration - Files | Page 35 3.5.4.1.1 System Parameters The Compliance Interface requires no specific system parameters for business functionality. 3.5.4.1.2 Profiles GPP uses profiles to determine how the system processes each transaction and payment-related message using the specific information associated with the transaction. 3.5.4.1.2.1 Currencies Preferences Profile The Currencies Preferences profile stores business-specific currency data. The Seized Funds Account field in the profile enables a financial institution to define the default credit account that GPP uses to seize the funds of a transaction when a user instructs to block the funds after the receipt of a Compliance Interface Hit response, or after the receipt of a Compliance Interface Block and Seize response. Note: A financial institution can define Credit Account Enrichment rules to override the defined value for specific scenarios. For more information about the Currencies Preferences profile, see the GPP Online Help. 3.5.4.1.3 Rules At various points during the transaction processing workflow, GPP invokes business rules to determine continued transaction processing and handling. 3.5.4.1.3.1 Compliance Validation Rules GPP invokes this type of rule to determine whether a transaction or a Return message requires compliance validation. If a transaction or a Return message meets a rule’s criteria, GPP performs the defined Action field. The field can contain one of the following: BYPASS: GPP does not invoke the Compliance Interface for the specific transaction or Return message that meets the rule’s criteria. SANCTIONS: GPP invokes the Compliance Interface for the specific transaction or Return message that meets the rule’s criteria. 3.5.4.1.3.2 Credit Account Enrichment Rules GPP invokes this type of rule to allow overriding the regularly derived credit account for a transaction or Return message with an alternative account. During the Sub-batch Completion flow, GPP invokes this rule type to override the credit account for various reasons. But in the context of the Compliance interface this may be an alternative seizing account in a case a seizing of the funds is required: An authorized user performs a manual Block action to seize the funds of a transaction or a Return message. For more information, see Manual Handling. A transaction or a Return message receives a Hit and Seize response from the Compliance Interface. For more information, see Details. 3.5.4.2 System Configuration GPP uses system reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining system reference data, GPP can tailor system behavior to specific financial institution requirements. Note: GPP supplies a full set of system reference data that are customized to specific financial institution requirements. In most cases, authorized GPP users can view, but not update, system reference data. GPP PAYplus | System Integration - Files | Page 36 3.5.4.2.1 System Parameters The Compliance Interface requires no specific system parameters. 3.5.4.2.2 Profiles GPP uses system profiles to determine how the system processes each transaction and paymentrelated message using the specific information associated with the transaction. 3.5.4.2.2.1 Interfaces Profile The Interfaces profile stores definitions about how GPP interacts and communicates with external systems. GPP uses the Non-active behavior field to determine continued transaction processing if a transaction is inactive. The field can have one of the following values: PERMANENT_STOP: If the interface is inactive, GPP stops transaction processing and routes the transaction to the Compliance Inactive queue. GPP does not continue processing the transaction after the interface becomes active. STOP_UNTIL_ACTIVE: If the interface is inactive, GPP stops transaction processing and routes the transaction to the Compliance Inactive queue. GPP continues processing the transaction when the interface becomes active. Relevant Interfaces profiles should be configured for the Compliance interface. The timeout and nonactive behavior, when relevant, should also be set in these entries according to the financial For a description of the relevant fields, see the GPP Online Help or the GPP Interfaces Technical Guide. Note: When GPP is defined to use the Fndt Message format structure for a specific interface type, GPP can also be set up to define which sections of the structure to send. This definition can be a maximum with a full structure (including all the message related attributes), to a minimum that is specific per interface type. For example for Compliance interface only the sections quoting the message texts. 3.5.4.2.3 Rules At various points during the transaction processing workflow, GPP invokes system rules to determine continued transaction processing and handling. 3.5.4.2.3.1 Interface Selection Rules The Compliance Interface requires Interface Selection rules, which GPP invokes to determine the most appropriate Interfaces profile for each transaction and payment-related message, flow, and invocation point. For more information, see Interfaces Profile. 3.5.5 Message Data The Compliance Interface requires no specific message attributes. 3.5.5.1 Audit Trail Entries GPP generates an Audit Trail entry for each transaction and Return message if a user performs a manual action on it in any of the related manual and wait queues. 3.5.5.2 Error Codes The following table describes the error codes that GPP might generate during compliance validation. GPP PAYplus | System Integration - Files | Page 37 Error Code Description 40138 Compliance hits were found. Returned by the Compliance Interface to indicate Hit response for a compliance validation error. 40142 Illegal setup - no compliance validation rule is defined. Returned by the Compliance Interface to indicate an illegal GPP setup that does not have a defined default Compliance Validation rule. For more information about GPP error logging during compliance validation, see Details. 4 Bulk Interface 4.1 Overview The GPP Bulk Interface enables financial institutions to send interface requests and receive interface responses in bulk files, instead of individually (see Interface Transmission Modes). GPP can be configured for Bulk Interface handling to meet specific financial institution requirements for an interface, such as the GPP Account Lookup interface (see Account Lookup Interface). GPP stores all outgoing requests to the specific interface in a dedicated database table until a designated sending time (see Sending Times Profile). At the sending time, the Bulk Interface generates an outgoing bulk interface file that contains all relevant individual interface requests from the database table and transmits the file to the relevant financial institution external system. For more information, see Outgoing Bulk Interface Handling Flow. GPP can also receive an incoming bulk interface file that contains multiple responses, or Feeder requests, from a specific external financial institution system. Upon receipt of the file, the Bulk Interface de-bulks all responses in the file for individual interface response, or Feeder request, processing. For more information, see Incoming Bulk Interface File Handling Flow. Note: The Bulk Interface is the default GPP configuration for file handling. 4.2 Processing GPP transaction processing includes both generic workflows and workflows dedicated to specific functionality and transaction types. 4.2.1 Details Upon receipt of a file containing one or more transactions from a clearing system, financial institution, or other channel, GPP begins processing each transaction and payment-related message in the file using the standard processing workflow for each type of transaction. At the exit point during transaction processing that GPP normally invokes specific interface functionality, such as a request to the Account Lookup interface, GPP invokes specific business rules to determine how to handle communication with the interface. GPP can be configured to invoke the Bulk Interface for handling a file that contains multiple interface requests or responses. Outgoing request bulk handling includes formatting each request in the relevant format and storing each in a dedicated database table until the defined sending time. For more information, see Outgoing Bulk Interface Handling Flow. Incoming response bulk handling includes parsing the incoming file and then processing each response individually. For more information, see Incoming Bulk Interface File Handling Flow. GPP PAYplus | System Integration - Files | Page 38 4.2.1.1 Outgoing Bulk Interface Handling Flow A financial institution can request to configure GPP with Bulk Interfaces for the various interface types, such as Account Lookup request, that are invoked during transaction processing. Note: The Bulk Interface is the default GPP configuration for file handling. At the relevant interface exit point during the transaction processing workflow, such as Account Lookup, GPP uses defined reference data to select and invoke the Single to Bulk and the Bulk Interfaces. GPP first invokes the defined single to bulk interface to handle the outgoing interface request. The single interface does the following: Formats the outgoing request into the Fndt Message format for the specific type of interface. Stores the request with a PENDING status in the FILE_INTERFACE_BUFFERS table. Routes the transaction to corresponding Wait queue or continues transaction processing, as configured and required for the defined Interfaces profile (see Interfaces Profile). GPP stores all pending requests in the FILE_INTERFACE_BUFFERS table until the designated sending time configured for the associated Bulk Interfaces profile. At the sending time, GPP generates an outgoing bulk interface file that contains a structured header and all pending requests for the relevant interface. The header contains file identification information. Each request is stored in a dedicated reoccurring tag in the body of the file, once occurrence for each request. After file generation, GPP transmits the file to the relevant external financial institution system. For more information, see Sending Times Profile. If GPP receives an exception when generating the bulk interface file, GPP rolls back all relevant requests to the FILE_INTERFACE_BUFFERS table and sets each with a PENDING status to wait for the next defined sending time. Note: If there are no pending requests for the relevant interface at the defined sending time, GPP does not generate or transmit a bulk interface file. 4.2.1.2 Incoming Bulk Interface File Handling Flow A financial institution can request to configure GPP with a Bulk Interface to process an incoming file that contains multiple interface responses for the various interface types, or multiple Feeder requests. GPP receives the file from an external financial institution system in response to a file containing multiple interface requests sent by GPP, or as a Feeder initiated by the financial institution system. Note: The Bulk Interface is the default GPP configuration for file handling. The incoming response file must contain a structured header, as required by GPP. The header identifies the file. The file also contains a body that must contain each incoming response in the dedicated reoccurring tag, one occurrence for each response. Upon receipt of an incoming interface file, GPP invokes a defined Incoming Bulk Response File interface. The Bulk Interface de-bulks the file into individual interface responses, or Feeder requests, and then invokes the appropriate defined Single interface (see Interfaces Profile) that performs the specific interface logic as described in the sections per the specific interface type. For bulk responses, the interface logic includes matching each response with the corresponding original transaction using the unique Message ID (MID) that GPP generates for each transaction and transaction-related message. If GPP fails to de-bulk the incoming interface file, GPP moves the file to a designated folder and no additional processing occurs. After matching a response and original transaction, GPP releases the transaction from the relevant Wait queue (if GPP routed it to the queue to wait for an interface response) and continues with the generic transaction processing workflow. GPP PAYplus | System Integration - Files | Page 39 4.3 Manual Handling The Bulk Interface requires no specific manual handling. 4.4 Business Setup and System Configuration GPP uses business setup and system configuration reference data to enable system operation, transaction processing, and UI functionality. 4.4.1 Business Setup GPP uses business reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining business rules, a bank or financial institution can tailor system behavior to specific business requirements. 4.4.1.1 System Parameters The Bulk Interface requires no specific system parameters for business functionality. 4.4.1.2 Profiles The Bulk Interface requires no specific business profiles. 4.4.2 System Configuration GPP uses system reference data, such as rules and profiles, to achieve flexibility in transaction and payment-related message processing. By creating and maintaining system reference data, GPP can tailor system behavior to specific financial institution requirements. Note: GPP supplies a full set of system reference data that are customized to specific financial institution requirements. In most cases, authorized GPP users can view, but not update, system reference data. 4.4.2.1 System Parameters The Bulk Interface requires no specific system parameters. 4.4.2.2 Profiles GPP uses system profiles to determine how the system processes each transaction and paymentrelated message using the specific information associated with the transaction. 4.4.2.2.1 Interfaces Profile The Interfaces profile stores definitions about how GPP interacts and communicates with external systems. The Bulk Interface uses the following Interfaces profile fields: Bulk-Single: Determines whether GPP interacts and communicates with the defined interface in bulk or as a single interface request or response. Bulk Interface Name: Defines the name of the relevant Bulk Interface. Note: Only relevant for a single interface. Bulking Trigger Method: Determines the type of event that triggers GPP to generate and transmit an outgoing bulk file of multiple interface requests and is only relevant for outgoing Bulk Interfaces profiles. Currently, GPP supports only a time-based method. The Bulk Interface requires the following Interfaces profiles: Outgoing Bulk: GPP uses this interface to retrieve outgoing requests from the FILE_INTERFACE_BUFFERS table at the defined sending time and send the file to the external system. The interface has the following definitions: GPP PAYplus | System Integration - Files | Page 40 - Bulk-Single = Bulk - Bulking Trigger Method = Time based - Direction = Out Incoming Bulk: GPP uses this interface for incoming bulk responses, or Feeder requests. The interface has the following definitions: - Bulk-Single = Bulk - Bulking Trigger Method = Null - Direction = In Outgoing Single: GPP uses this interface to perform the specific logic for each interface type, generate outgoing requests, and store them in the FILE_INTERFACE_BUFFERS table. GPP also uses this interface to determine the appropriate Bulk Interfaces profile that is invoked to bulk and send outgoing requests. The interface has the following definitions: - Bulk-Single = Single - Bulk Interface Name = - Bulking Trigger Method = Null - Direction = Out - Protocol = STORE_REQUEST Incoming Single: GPP uses this interface for de-bulked individual responses received in a bulk response file. The interface has the following definitions: - Bulk-Single = Single - Bulk Interface Name = - Bulking Trigger Method = Null - Direction = In For more information about profiles, see the GPP Online Help. 4.4.2.2.2 Sending Times Profile The Sending Times profile, associated with the Interfaces profile of a Bulk interface profile, stores definitions about the trigger events that GPP uses to determine when to generate and send files of bulk interface requests. The Bulk Interface uses the following profile fields: Time to send: Defines the time that GPP generates and sends a file of bulk interface requests. Send every: Defines a time period (in minutes) after which GPP generates and sends a file of bulk interface requests. For more information about profiles, see the GPP Online Help. 4.4.2.3 Rules At various points during the transaction processing workflow, GPP invokes business rules to determine continued transaction processing and handling. 4.4.2.3.1 Interface Selection Rules The Bulk Interface requires Interface Selection rules, which GPP invokes to determine the most appropriate Interfaces profile for each transaction, flow, and invocation point. GPP PAYplus | System Integration - Files | Page 41 Appendix A: Manual Actions per Queue Only the manual actions that 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: Actions are always available (subject to specific user permissions) unless explicitly stated otherwise. Interface Type Queue Action Button Description Account Lookup Wait CDB Response Cancel Initiates the cancelation of the transaction. The transaction is routed to cancellation flow. Account Lookup Inactive CDB Cancel Initiates the cancelation of the transaction. The transaction is routed to cancellation flow. Account Lookup Posting Restrictions Override Overrides the restriction. MU_STOP_FLAGS_OVERRIDE_STS is set to O, to indicate that the posting restriction override, and processing continues from this point in the flow. For Account Lookup, the relevant CDB monitor is set to P to skip an additional Account Lookup invocation on the account when a message is reprocessed. Note: The action button is only available to override the restriction when a transaction or S message was stopped due to a Stop Flag that can be overridden. Account Lookup Posting Restrictions Cancel Initiates the cancelation of the transaction or the S message and all its relevant I transactions. The transaction is routed to cancellation flow. 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. GPP PAYplus | System Integration - Files | Page 42 Interface Type Queue Action Button 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). 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). 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 example replace the Credit Account with a Suspense Account. GPP PAYplus | System Integration - Files | Description Page 43 Interface Type Queue Action Button Description Compliance Repair Cancel Initiates the cancelation of the outgoing transaction, including earmark release and reverse posting, when required. Account Lookup / Balance Inquiry Repair Submit Submits the transaction for reprocessing after user amendments to the transaction details. When reaching the point/s of Account Lookup o 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 o 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. o 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. 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. Account Lookup / Balance Inquiry Repair Cancel Initiates the cancelation of the transaction. The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required. Balance Inquiry 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 GPP PAYplus | System Integration - Files | Page 44 Interface Type Queue Action Button Description 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. Note: Only entitled users whose user profile maximum force limit amount is greater than the message amount can use this action button. Balance Inquiry 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. Balance Inquiry Insufficient Funds Send to Repair GPP sends the transaction to the Repair queue for manual adjustments. Balance Inquiry Insufficient Funds Cancel Initiates the cancelation of the transaction. The transaction is routed to cancellation flow, including earmark release, when required, or reverse posting, when required. Account Lookup / Balance Inquiry Posting Restrictions Override GPP overrides the restriction MU_STOP_FLAGS_OVERRIDE_STS is set to O, to indicate that the posting restriction was overridden, and processing continues from this point in the flow. For Account Lookup, if the relevant CDB monitor is not already P (if the failure with posting restrictions returned in an Account Lookup response), it is set to P to allow skipping an additional invocation of the Account Lookup on this account, when message is reprocessed. For Balance Inquiry, when reaching the point of Balance Check, whether the first time or as part of the re-processing, but only if the BI monitor is not P (meaning that the transaction was routed to this queue later in the flow due to a Posting response), the Balance inquiry interface generates a request to the HOST system, quoting a new event ID and indicating that the restriction was overridden (if GPP PAYplus | System Integration - Files | Page 45 Interface Type Queue Action Button Description 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. 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 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 Restrictions Send to Repair Sends the message to the Repair queue for manual adjustments. Account Lookup / Balance Inquiry 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. Appendix B: Glossary Term Description CDB Customer Database GPP PAYplus | System Integration - Files | Page 46 1 Term Description Feeder A customer-facing (front-end) system that enables transaction capture. Fndt Message FuNDs Transfer Message A GPP-specific XML structure that includes the full set of information as received, enriched, computed, or manually updated for each message. The structure is used as part of the standard interfaces for interacting with financial institution systems. GPP Global PAYplus Finastra’s state-of-the-art global payment services hub that is designed to extend GPP’s market-leading performance, scalability, and reliability to a serviceoriented architecture (SOA) compliant platform. ISO International Organization for Standardization An independent, non-governmental international organization that aims to facilitate the international coordination and unification of industrial standards. MQ IBM WebSphere®1 MQ A messaging solution that enables independent and potentially non-concurrent applications on a distributed system to securely communicate with each other. MOP Method of Payment The means via which GPP executes a transaction, such as BOOK or SWIFT. OFAC Office of Foreign Assets Control An agency of the United States Department of the Treasury that administers and enforces economic and trade sanctions based on U.S. foreign policy and national security goals. PDO Payment Data Object Data object that holds all payment data, including: XML message data (original and enriched) Relational data Reference data Rates, fees, errors, and so on PNL P&L Profit and Loss Account STP Straight-Through Processing A concept that enables GPP to process payment transactions to completion without the need for manual intervention. STP enables shortened processing cycles, reduced settlement risk, and lower operating costs. IBM and WebSphere are registered trademarks of IBM in the United States and other countries. GPP PAYplus | System Integration - Files | Page 47
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 - Files Title : Business Guide Create Date : 2018:01:01 13:35:44+02:00 Creator Tool : Microsoft® Word 2016 Modify Date : 2018:01:01 13:35:54+02:00 Metadata Date : 2018:01:01 13:35:54+02:00 Producer : Microsoft® Word 2016 Document ID : uuid:7a9d14bd-9a01-42a3-bd08-ea3334ddac8a Instance ID : uuid:fcda216d-e166-430f-ab2d-3b86de28796b Page Mode : UseOutlines Page Count : 47 Author : Finastra Subject : System Integration - FilesEXIF Metadata provided by EXIF.tools