Business Guide GPP System Integration Files

User Manual: Pdf

Open the PDF directly: View PDF .
Page Count: 47

1 Introduction
- 1.1 Documentation References
- 1.2 Target Audience
2 High Level Integration Flow
3 Interface Types
4 Bulk Interface
Appendix A: Manual Actions per Queue
Appendix B: Glossary

GPP PAYplus

System Integration - Files

Technical Guide

Product Version: 4.6.8

Catalog ID: GPP4.6-00-B55-01-201801

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.

GPP PAYplus | System Integration - Files | Page 3

Version Control

Version

Date

Summary of Changes

1.0

Aug 2017

Document created

 
GPP PAYplus | System Integration - Files |   Page 4 
Table of Contents 
INTRODUCTION .......................................................................................................................... 5 
1 Documentation References .................................................................................................. 5 
2 Target Audience .................................................................................................................... 5 
HIGH LEVEL INTEGRATION FLOW .......................................................................................... 6 
INTERFACE TYPES .................................................................................................................... 6 
1 Overview ............................................................................................................................... 6 
2 Interface Transmission Modes .............................................................................................. 6 
3 Account Lookup Interface ..................................................................................................... 7 
3.1 Overview ............................................................................................................................ 7 
3.2 Processing ......................................................................................................................... 8 
3.3 Manual Handling.............................................................................................................. 15 
3.4 Business Setup and System Configuration ..................................................................... 17 
3.5 Message Data ................................................................................................................. 19 
4 Balance Inquiry Interface .................................................................................................... 19 
4.1 Overview .......................................................................................................................... 19 
4.2 Processing ....................................................................................................................... 20 
4.3 Manual Handling.............................................................................................................. 26 
4.4 Business Setup and System Configuration ..................................................................... 27 
4.5 Message Data ................................................................................................................. 30 
5 Compliance Interface .......................................................................................................... 30 
5.1 Overview .......................................................................................................................... 30 
5.2 Processing ....................................................................................................................... 30 
5.3 Manual Handling.............................................................................................................. 33 
5.4 Business Setup and System Configuration ..................................................................... 35 
5.5 Message Data ................................................................................................................. 37 
BULK INTERFACE .................................................................................................................... 38 
1 Overview ............................................................................................................................. 38 
2 Processing .......................................................................................................................... 38 
2.1 Details .............................................................................................................................. 38 
3 Manual Handling ................................................................................................................. 40 
4 Business Setup and System Configuration ........................................................................ 40 
4.1 Business Setup................................................................................................................ 40 
4.2 System Configuration ...................................................................................................... 40 
APPENDIX A: MANUAL ACTIONS PER QUEUE ............................................................................... 42 
APPENDIX B: GLOSSARY .................................................................................................................. 46 

GPP PAYplus | System Integration - Files | Page 5

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 6

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.

Integration Layer

Global PAYplus

Internal Integration / Transformation Layer

Order Management

Last Mile Solutions

Ecosystem

Interfaces

CLEARING

NETWORK

Integration Layer

Core Banking

Customer DB

Notification

File

Processing

Validation and

Enrichment

Single Payment

Initiation

Ack and

Notification

CIF

Lookup

Account

Posting

Sanctions

(Roadmap)

Customer

Advising

Payment Execution

Immediate

Payments

Infrastructure and Data Layer

Liquidity &

Risk

Management

High Value Mass

Payments

Core Services

SWIFT Euro1T2

Replication DB

Feeder

Integration Layer

Services

& Uploads

Queue List

SWIFT

RMA

upload

Profile

Upload

Fees and

Billing

Balance

Check

Sanctions / Fraud

FATF

Sanctions / Fraud

FATF

Billing Engine

(Roadmap)

Reference

Data

Reference

Data

Investigation

Reporting

BAM

Real Time

FX Engine

Real Time

FX Engine

SAA

SWIFTref

upload

Standard

Interfaces

Legend

Best

Practice

Channels

Internal Integration / Transformation Layer

Future

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 7

 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 8

 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 9

The following shows the Account Lookup in the transaction processing workflow.

Load account and

party from GPP

Start Dr/Cr side

Processing

Success

External lookup

set?

Account

Lookup Rule

found?

Create account

lookup request

Continue file

transaction flow

Posting

restrictions

Wait Behavior

WaitCDB

Response

received

Successful

response?

(MI_CDB_STS=N)

Yes

Repair

Yes

No,

Failure

response

Yes

(MI_CDB_STS=P)

Change account

and Submit

Canceled

Cancel

Yes

Posting

Restrictions

POSTREST

Override Post. Rest

(if stop flags

is overridable)

(new EventID)

Send to

Repair

Retry Post.Rest –

to resend

with retry monitor

(new EventID)

User

Action

User

Action

A-Sync

interface?

Yes

In Pre-

Processing and

Target side?

Yes

Credit Side

Enrichment with

DUMMY Account

GPP PAYplus | System Integration - Files | Page 10

3.3.2.2 Details

3.3.2.2.1 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 11

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 12

 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 Pre-

Processing 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 Pre-

Processing 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 13

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 14

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:

- 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.

3.3.2.3 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 15

 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 the <ContexName> and <contexLocalName> 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 16

 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 17

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 18

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 19

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 20

 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 21

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 22

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 23

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 24

 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 25

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 26

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 <ContexName> and <contexLocalName> 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 27

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 28

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 29

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 payment-

related 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

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 30

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 31

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 32

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 <ContexName> and <contexLocalName> 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 33

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 34

 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 Sub-

batch 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 35

 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 36

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 37

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 payment-

related 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 non-

active 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 38

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 39

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 40

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 payment-

related 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 41

- 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 = <Interface Name of the relevant outgoing Bulk Interfaces profile>

- 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 = <Interface Name of the relevant incoming Bulk Interfaces profile>

- 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 42

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

Inq.

Response

Force

GPP continues processing even though the no

response was received.

Note: Only entitled users whose user profile

maximum force limit amount is greater than the

message amount can use this action.

Balance

Inquiry

Wait Balance

Inq.

Response

Retry Bal. Inq.

GPP retries the processing of the message.

The CDB monitor is kept as P, if external Account

Lookup is required and was performed earlier in

the flow, to allow skipping an additional

invocation of the Account lookup, when message

is reprocessed.

When reaching the points in the flow for. another

request - Balance inquiry, and as the Balance

Inquiry monitor is not set to P, as an indication

that this step already ended successfully, GPP

generates a new request to the HOST system,

quoting a new Event ID. The transaction is routed

to Wait Balance Inq. (BIWAITQ) pending

response from HOST system.

GPP PAYplus | System Integration - Files | Page 43

Interface

Type

Queue

Action Button

Description

Balance

Inquiry

Wait Balance

Inq.

Response

Send to Repair

GPP sends the message to the Repair queue for

manual adjustments

Balance

Inquiry

Wait Balance

Inq.

Response

Cancel

Initiates the cancelation of the transaction.

The transaction is routed to cancellation flow,

including earmark release, when required, and

reverse posting, when required (for example, if

the Balance Inquiry is pending on the second leg

(target debit account), and Posting was already

performed on first leg).

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 | Page 44

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 45

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 46

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 47

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 service-

oriented 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.

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.

Business Guide GPP System Integration Files

Navigation menu

Versions of this User Manual:

Views

Navigation