Business Guide GPP System Integration Single Transactions

User Manual: Pdf

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

GPP PAYplus
System Integration - Single
Transactions
Technical Guide
Product Version: 4.6.8
Catalog ID: GPP4.6-00-B54-01-201801
Copyright
© 2009-2018 Finastra International Limited, or a member of the Finastra group of companies (“Finastra”). All
Rights Reserved. Confidential - Limited Distribution to Authorized Persons Only, pursuant to the terms of the
license agreement by which you were granted a license from Finastra for the applicable software or services and
this documentation. Republication or redistribution, in whole or in part, of the content of this documentation or any
other materials made available by Finastra is prohibited without the prior written consent of Finastra. The
software and documentation are protected as unpublished work and constitute a trade secret of Finastra
International Limited, or a member of the Finastra group of companies, Head Office: One Kingdom Street,
Paddington, London W2 6BL, United Kingdom.
Disclaimer
Finastra does not guarantee that any information contained herein is and will remain accurate or that use of the
information will ensure correct and faultless operation of the relevant software, services or equipment. This
document contains information proprietary to Finastra. Finastra does not undertake mathematical research but
only applies mathematical models recognized within the financial industry. Finastra does not guarantee the
intrinsic theoretical validity of the calculation models used.
Finastra, its agents, and employees shall not be held liable to or through any user for any loss or damage
whatsoever resulting from reliance on the information contained herein or related thereto. The information
contained in this document and the general guidance of Finastra staff does not take the place of qualified
compliance personnel or legal counsel within your institution.
FINASTRA CANNOT RENDER LEGAL, ACCOUNTING OR OTHER PROFESSIONAL SERVICES TO YOUR
INSTITUTION. THE INFORMATION CONTAINED HEREIN IS GENERAL IN NATURE AND DOES NOT
CONSTITUTE LEGAL ADVICE OR A LEGAL OPINION. CONSULT YOUR LEGAL COUNSEL FOR LEGAL
ADVICE SPECIFIC TO YOUR SITUATION OR CIRCUMSTANCES OR TO ANSWER ANY LEGAL
QUESTIONS.
This document is not intended as a substitute for formal education in the regulatory requirements of banking,
banking operations, lending, lending operations, or other topics generally applicable to financial institutions. Your
financial institution is solely responsible for configuring and using the software or services in a way that meets
policies, practices, and laws applicable to your institution, including, without limitation: (1) options and selections
made on prompts; (2) entries in the software program; (3) program setup; and (4) documents produced by the
software or services. It is the obligation of the customer to ensure that responsible decisions are taken when
using Finastra products. Information in this document is subject to change without notice and does not represent
a commitment on the part of Finastra.
Feedback
Do you have comments about our guides and online help? Please address any comments and questions to your
local Finastra representative.
Need more information? Read more about our products at http://www.finastra.com or contact your local Finastra
office at http://www.finastra.com/contact.
GPP PAYplus | System Integration - Single Transactions | Page 3
Version Control
Version
Date
Summary of Changes
1.0
Document Created
2.0
March 2016
Added Compliance and Online Foreign Exchange Interfaces
3.0
June 2016
Some formatting and rephrasing updates
3.1
Nov 2016
Addition of a note regarding the non-persistence of account and
customer attributes fetched through Account Lookup
3.2
Feb 2017
Addition of a more specific instruction as per the content of customer
attributes returned from Account Lookup
3.3
April 2017
Update Balance Inquiry section:
A fix of available buttons in Balance Wait queue
A fix in the phrasing for the Balance Reservation request process
and required configuration, and in the phrasing of automatic retires
of Balance Inquiry
An additional note in the Account Lookup section describing the
addition of the IBAN to the Request when it is provided in the
transaction.
3.4
May 2017
Updated with missing action from Posting Exception queue
Added the Seize functionality to Compliance Interface, Processing
section
3.5
July 2017
Updated with change in the alias of the External Interface checkbox
in Accounts profile
Move order of paragraphs in Processing section of Account Lookup
Added a bullet in Response handling (in all chapters) regarding the
Timeout functionality
3.6
Aug 2017
Updated with a note regarding configuration not to store Feeder
message in Processing Communications
GPP PAYplus | System Integration - Single Transactions | Page 4
Table of Contents
1 INTRODUCTION .......................................................................................................................... 6
1.1 Documentation References .................................................................................................. 6
1.2 Target Audience .................................................................................................................... 7
2 HIGH LEVEL INTEGRATION FLOW .......................................................................................... 7
3 ACCOUNT LOOKUP INTERFACE ............................................................................................. 8
3.1 Overview ............................................................................................................................... 8
3.2 Processing .......................................................................................................................... 10
3.2.1 Workflow .......................................................................................................................... 10
3.2.2 Details .............................................................................................................................. 11
3.2.3 Response/Request Matching .......................................................................................... 13
3.3 Manual Handling ................................................................................................................. 13
3.3.1 Wait Queues .................................................................................................................... 14
3.3.2 Inactive Queues............................................................................................................... 14
3.3.3 Manual Handling Queues ................................................................................................ 14
3.3.4 Resume from Manual or Wait Statuses .......................................................................... 16
3.4 Business Setup and System Configuration ........................................................................ 16
3.4.1 Business Setup................................................................................................................ 16
3.4.2 System Configuration ...................................................................................................... 17
3.5 Message Data ..................................................................................................................... 18
4 BALANCE INQUIRY INTERFACE ............................................................................................ 18
4.1 Overview ............................................................................................................................. 18
4.2 Processing .......................................................................................................................... 18
4.2.1 Balance Check ................................................................................................................ 18
4.2.2 Earmark Release ............................................................................................................. 23
4.2.3 Automatic Retries ............................................................................................................ 24
4.2.4 Response/Request Matching .......................................................................................... 25
4.3 Manual Handling ................................................................................................................. 25
4.3.1 Wait Queues .................................................................................................................... 26
4.3.2 Inactive Queues............................................................................................................... 26
4.3.3 Manual Handling Queues ................................................................................................ 27
4.4 Business Setup and System Configuration ........................................................................ 29
4.4.1 Business Setup................................................................................................................ 29
4.4.2 System Configuration ...................................................................................................... 31
4.5 Message Data ..................................................................................................................... 32
5 COMPLIANCE INTERFACE ..................................................................................................... 32
5.1 Overview ............................................................................................................................. 32
5.2 Processing .......................................................................................................................... 33
5.2.1 Workflow .......................................................................................................................... 33
5.2.2 Details .............................................................................................................................. 33
5.2.3 Response/Request Matching .......................................................................................... 34
5.3 Manual Handling ................................................................................................................. 34
5.3.1 Wait Queues .................................................................................................................... 35
5.3.2 Manual Handling Queues ................................................................................................ 35
5.4 Business Setup and System Configuration ........................................................................ 36
GPP PAYplus | System Integration - Single Transactions | Page 5
5.4.1 Business Setup................................................................................................................ 36
5.4.2 System Configuration ...................................................................................................... 38
5.5 Message Data ..................................................................................................................... 39
6 FEEDER INTERFACE ............................................................................................................... 39
6.1 Overview ............................................................................................................................. 39
6.2 Processing .......................................................................................................................... 40
6.2.1 Workflow .......................................................................................................................... 40
6.2.2 Details .............................................................................................................................. 40
6.3 Manual Handling ................................................................................................................. 47
6.3.1 Wait Queues .................................................................................................................... 47
6.3.2 Manual Handling Queues ................................................................................................ 47
6.4 Business Setup and System Configuration ........................................................................ 47
6.4.1 Business Setup................................................................................................................ 47
6.4.2 System Configuration ...................................................................................................... 48
6.5 Message Data ..................................................................................................................... 49
7 ONLINE FOREIGN EXCHANGE INTERFACE ......................................................................... 49
7.1 Overview ............................................................................................................................. 49
7.2 Processing .......................................................................................................................... 50
7.2.1 Workflow .......................................................................................................................... 50
7.2.2 Details .............................................................................................................................. 51
7.3 Manual Handling ................................................................................................................. 51
7.3.1 Wait Queues .................................................................................................................... 52
7.3.2 Manual Handling Queues ................................................................................................ 52
7.4 Business Setup and System Configuration ........................................................................ 53
7.4.1 Business Setup................................................................................................................ 53
7.4.2 System Configuration ...................................................................................................... 54
7.5 Message Data ..................................................................................................................... 54
8 POSTING INTERFACE ............................................................................................................. 55
APPENDIX A: MANUAL ACTIONS PER QUEUES ............................................................................ 56
APPENDIX B: GLOSSARY .................................................................................................................. 64
GPP PAYplus | System Integration - Single Transactions | Page 6
1 Introduction
Note: This document has not yet been certified for GPP V4.6; therefore, there may be inaccuracies in
this document that may require amendments in the future. For more information, please contact your
Finastra Project Manager.
Global PAYplus (GPP) can integrate with a financial institution’s systems via various interfaces. Each
interface is dedicated to a specific functionality.
GPP provides a standard message structure, which is referred to as the Fndt Message (FuNDs
Transfer Message). The structure is used for the interfaces which are decoupled from the functionality
around the interfaces’ invocation and usage of the information they provide as part of the GPP
processing.
This Business Guide describes the business functionality as part of single payment processing and
manual handling that is supported in relation to the supported interfaces. The request and response
details are available in the relevant Interface Technical Guide. For the list of technical guides, see
Documentation References.
Note: This document describes the business processing, manual handling and configuration required
for GPP standard interfaces except for the Posing interface. For a description of the Posting interface,
see GPP Business Guide Posting.
1.1 Documentation References
These GPP documents are referred to in this business guide.
Comments
1.
Describes the full Fndt Message structure
2.
Describes the minimal scope and additional optional
sections that can be added for additional functionality, when
using the Standard Fndt Message structure for Feeder
request and acknowledgment.
3.
Describes the minimal scope and additional optional
sections that can be added for additional functionality, when
using the Standard Fndt Message structure for Account
Lookup request and response.
4.
Describes the minimal scope and additional optional
sections that can be added for additional functionality, when
using the Standard Fndt Message structure for Balance
Inquiry request and response.
5.
Describes the minimal scope and additional optional
sections that can be added for additional functionality, when
using the Standard Fndt Message structure for Posting
request and response.
6.
Describes the business functionality of the Posting logic in
GPP. This Business Guide includes information on the
various Accounting models that can be supported, describes
the required configuration and the manual handling around
the Posting logic.
7.
Describes the minimal scope and additional optional
sections that can be added for additional functionality, when
GPP PAYplus | System Integration - Single Transactions | Page 7
Comments
using the Standard Fndt Message structure for Compliance
request and response.
8.
Describes technical options and configuration of the different
attributes in the Interfaces profile.
1.2 Target Audience
This business guide is intended for business analysts and product managers that need to understand
the integration capabilities including the configuration and utilization per each interface type supported
by GPP.
2 High Level Integration Flow
GPP supports invocation of various interfaces during its single payment processing flows, each for a
specific functionality. This business guide describes the business functionality for each of the
supported interfaces.
Integration Layer
Global PAYplus
Internal Integration / Transformation Layer
Order Management
Last Mile Solutions
Ecosystem
Interfaces
CLEARING
NETWORK
Integration Layer
Integration Layer
Core Banking
Core Banking
Customer DB
Customer DB
Notification
Notification
File
Processing
Validation and
Enrichment
Single Payment
Initiation
Ack and
Notification
CIF
Lookup
Account
Posting
Sanctions
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
Billing Engine
FX
Reference
Data
Reference
Data
Investigation
Investigation
Reporting
Reporting
BAM
BAM
Real Time
FX Engine
Real Time
FX Engine
SAA
SAA
SWIFTref
upload
Standard
Interfaces
Legend
Best
Practice
Channels
Channels
Internal Integration / Transformation Layer
Future
GPP PAYplus | System Integration - Single Transactions | Page 8
3 Account Lookup Interface
3.1 Overview
Account lookup is performed in GPP to retrieve account and customer information required for
successful processing.
This interface is always called within the context of a transaction. The interface may be invoked after
debit/credit derivation and used for loading the debit/credit account details.
Note: the account and customer attributes (F_ fields) retrieved using the Account Lookup are
available to be used in processing rules during the processing of the transaction. However, once the
transaction reaches the final status this information is not kept in the context of the transaction. It can
be viewed as part of the structure of the Account Lookup Response within the full XML structure via
the Processing Communication page, but cannot be used for searching or filtering the repository of
transactions.
GPP evaluates the Account Lookup business rules when either the credit account or the debit
account is not an account maintained in the GPP Accounts profiles repository, or if the account does
exist but it is marked to invoke the Account Lookup interface (External lookup checkbox is selected).
Based on the rules evaluation results, if the selected rule contains the action External, GPP invokes
the Account Lookup interface.
GPP does not perform Account Lookup for Fee accounts.
Once the Account Lookup interface is invoked, and if the interface is working in A-sync mode, the
message processing is stopped and the message waits for the response in the queue (status) of Wait
CDB response (CDBWAIT).
Account information expected to be captured from the Account Lookup response may include the
following:
Holding customer identification, Name, and Address details (Country, State, City, Zip, Street
Address)
Customer and account categorization that may affect processing (such as FX and Fees)
Booking entity the account is assigned to (accounting system in which the account is managed)
Account type, the values are as defined in GPP Account Types profiles
Posting restriction that may exist on the account
When a failure in the request processing occurs on the HOST, response details are expected to
specify the errors encountered in the request processing. These errors may be related to a technical
issue, or functional issue.
The message processing is resumed in GPP after the receipt of the Account Lookup response based
on the response received:
If positive response with no posting restrictions, GPP stores the account information and the
message continues the processing to the next step.
If a response with posting restrictions, the message is routed to the Posting Restriction
(POSTREST) queue, for manual override or retry.
If negative response, either technical or functional, the message is routed to the Repair (REPAIR)
queue, for manual handling.
GPP supports a GPP Standard Account Lookup format that is suggested to be used for this interface.
For more details on this format, see GPP Technical Guide - Fndt Message Usage for Account Lookup
Interface document.
GPP PAYplus | System Integration - Single Transactions | Page 9
GPP can also support a proprietary format as per the financial institution’s preference, once initial
mapping effort is included between the proprietary format and the GPP attributes, and as long as the
necessary information exists in this proprietary format.
GPP PAYplus | System Integration - Single Transactions | Page 10
3.2 Processing
3.2.1 Workflow
Load account and
party from GPP
DB
Start Dr/Cr side
Processing
Success
External lookup
set?
Evaluate Account
Lookup Selection
rules
Account
Lookup Rule
found?
Create account
lookup request
Continue HV
payment flow
Posting
restrictions
Wait Behavior
WaitCDB
Response
received
Successful
response?
No
(MI_CDB_STS=N)
Yes
No
Yes
Repair
No
Yes
No,
Failure
response
Yes
(MI_CDB_STS=P)
No
Change account
and Submit
Canceled
Cancel
Yes
No
Copy and resend
original request
with a new delivery
timestamp
(same EventID)
Resend from
MEI screen
Send to
Repair
Yes
User Action
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
GPP PAYplus | System Integration - Single Transactions | Page 11
3.2.2 Details
3.2.2.1 Handling Account Lookup Request
These are the different scenarios for Account Lookup Invocation:
Outgoing (feeder/manual create) Credit Transfer transactions: GPP performs Account
Lookup in the following cases:
- On the debit account: Debtor account identification is provided in the message but additional
required information is not provided, and the debtor account does not exist in GPP, or exists
in GPP but is marked to be rechecked in Host (External lookup checkbox is selected). It is
assumed that the debtor is a financial institution’s customer.
- On the credit account: Credit account identification is provided in the message without the
additional required information, and creditor is a financial institution’s customer (creditor agent
is the local office), and credit account does not exist in GPP, or exists in GPP but is marked to
be rechecked in Host (External lookup checkbox selected).
Outgoing (feeder/manual create) Debit Transfer (collection) transactions: GPP performs
Account Lookup in the following cases:
- On the debit account: Debtor account identification is provided in the message but additional
required information is not provided, the debtor is a financial institution customer (debtor
agent is the local office), and the debtor account does not exist in GPP, or exists in GPP but
is marked to be rechecked in Host (External lookup checkbox selected).
- On the credit account: Credit account identification is provided in the message without the
additional required information, and credit account does not exist in GPP, or exists in GPP but
is marked to be rechecked in Host (External lookup checkbox selected).
Incoming Credit Transfer transactions: GPP performs Account Lookup in the following case:
- On the credit account: Credit account identification is provided in the message without the
additional required information, and credit account does not exist in GPP, or exists in GPP but
is marked to be rechecked in Host (External lookup checkbox selected). It is assumed that the
creditor is a financial institution’s customer (otherwise the transaction is an onward
transaction).
Incoming Debit (Collection) transactions: GPP performs Account Lookup in the following case:
- On the debit account: Debtor account identification is provided in the message without the
additional required, and the debtor account does not exist in GPP, or exists in GPP but is
marked to be rechecked in Host (External lookup checkbox selected). It is assumed that the
debtor is a financial institution’s customer.
Onward transactions: GPP is not expected to perform Account Lookup as none of the accounts
(debit/credit) are a customer account.
Note: When an IBAN is provided as the account in the transaction, this IBAN, in addition to the
deconstructed Account Number, is also sent within the Account Lookup request, to allow identification
by it in the financial institution’s system.
GPP can include in the request a unique 16 character Event ID each time the transaction triggers the
Account Lookup interface (if using the GPP Standard Account Lookup format this ID is quoted in the
EventID tag within the Header section):
When it is an override request, the request is sent quoting a new Event ID.
When it is a re-invocation after manual or wait queue, the request is sent quoting a new Event ID.
When it is resend, the request is sent quoting the original Event ID.
The Event ID is stored in the Message external interaction (EVENT_ID column), for interfaces that are
configured to create a MESSAGE_EXTERNAL_INTERACTION entry, and the
EVENT_ID_GENERATION field is set to 1 in their INTERFACE_TYPES entry. It is generated with the
GPP PAYplus | System Integration - Single Transactions | Page 12
algorithm being similar to MID generation, including letters, numbers, and date & time, and it is saved,
and can be used, in the D_MEI_EVENT_ID Logical Field.
GPP stores the request in the Processing Communications (MESSAGE_EXTERNAL_INTERACTION
table), when the Interface entry is configured to instruct so.
For all of the scenarios of Account Lookup Invocation, whenever the message is released from a
manual or wait queue (for example Posting Exception, Schedule), another validation request via
Account lookup is sent to the HOST system, to make sure that the account is still valid.
3.2.2.2 Handling Account Lookup Response
GPP parses the response.
GPP validates that the response is structurally valid, against the relevant defined structure, either
the Standard Fndt Message or a financial institution specific proprietary structure per this interface
type.
GPP performs matching between the response and the relevant request. For more details on the
matching functionality see Response/Request Matching.
GPP stores the response in the Processing Communications
(MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct
so.
Audit trail of the transaction is updated to indicate that a response was received. For a negative
response, a response error description is also added to the message error log.
GPP evaluates the response value to decide to where it should route the transaction. For more
information, see Successful Response and Failure Response.
If a previous response was already received for the matched request (automatic or manual retry
were performed and the original response was received after the retried request was sent) and
the message already continued the processing, the latest response is ignored (saved in
Processing Communications (MESSAGE_EXTERNAL_INTERACTION) for the record, if
configured so, but does not affect the processing).
If the response is not received within a configurable timeout period, timeout will be retried per
configured number of retries on the Interface Type, after which - Interface becomes inactive and
Account Lookup request is treated as failed. For more details on Interface Timeout behavior, see
GPP Technical Guide - Interfaces document.
3.2.2.2.1 Successful Response
GPP validates that the response contains the required information.
- GPP expects the response to contain Creditor (full or reference to a Party configured in GPP
using the External Id attribute) and Credit Account information if the request provided the
Creditor account Identification and was sent with <contexName> of CreditAccountLookup.
- GPP expects the response to contain Debtor (full or reference to a Party configured in GPP
using the External Id attribute) and Debit Account information if the request provided the debit
account identification and was sent with <contexName> of DebitAccountLookup.
GPP captures the information provided in the Account Lookup response.
GPP stores the information in the transaction data.
- When the fee information is provided in the Account Lookup response, GPP captures and
stores the message fees information. For more information, see Capturing and Storing
Message Fees.
- When the contact information is provided in the Account Lookup response, GPP stores a
Contact details occurrence per each contact, reflecting its association to either the debit or
credit account or party.
GPP PAYplus | System Integration - Single Transactions | Page 13
3.2.2.2.1.1 Capturing and Storing Message Fees
Same functionality and handling as if received from Feeder. For more information, see Capturing and
Storing Message Fees.
3.2.2.2.2 Failure Response
GPP captures the error reasons provided in the response details.
If required, GPP maps the provided errors to GPP errors, based on a predefined error mapping
conversion.
GPP adds these errors to the message errors.
GPP routes the transaction to the relevant queue (Posting Restrictions (POSTREST) or Repair
(REPAIR)) based on the response received. For more information, see details in Manual
Handling.
3.2.2.3 Usage of Information Received During Processing
Later in the process, GPP uses the information received in the Account Lookup response for:
Account validation
Debtor/Creditor information enrichment, for example, with name and address information required
in the transaction submitted to clearing scheme.
Fee calculation – For more information, see Usage of Fees Information.
Balance inquiry
Posting restriction check, if restrictions were reported.
Posting entries generation (including entries for the fees reported in this response) and posting
interface
Advising (using the contact information provided in the response)
3.2.2.3.1 Usage of Fees Information
Same functionality and handling as if received from Feeder. For more information, see Usage of Fees
Information.
3.2.3 Response/Request Matching
In general, on Request/Response interfaces GPP supports a functional and technical matching
functionalities between the request, sent from GPP, and the response, received from the external
financial institution system. The functional, and more generic, method is the usage of <ContecName>
and <contexLocalName>, quoting, in the response, their value/s from the request + the P_MID.
Specifically for Account Lookup the usage of <contexName> in matching ensures matching of debit
side Account Lookup response to the debit side Account Lookup request, and the same for credit
side. There are additional technical methods that allow echo back of the sending system (GPP in
these cases) identifier in a custom property of the MQ header (the value of this identifier was captured
from the request as transport property) or using the MQ correlation Id in the MQ envelope.
Note: The Event ID currently is not used in the matching, therefore, it is not mandatory to be returned
in the response.
3.3 Manual Handling
This section describes the various scenarios in which a single transaction may be stopped in relation
with the Account Lookup interface:
In a wait queue until the relevant response is received, or
In an inactive queue until the interface is active again, or
A manual queue due to information received from the response
GPP PAYplus | System Integration - Single Transactions | Page 14
The description is per such specific manual queues. For a summary of actions per queue, see
Appendix A: Manual Actions per Queues.
3.3.1 Wait Queues
3.3.1.1 Wait CDB Response (CDBWAIT) Queue
A single transaction is stopped in this queue after an a-sync Account Lookup request is sent to the
external system, and until an Account Lookup response is received. When using sync mode the
process is not stopped but waits for an online response, and the transaction is not parked in any
queue.
In this queue the user only has the action of Cancel.
GPP Processing:
The transaction is routed to cancellation flow, including earmark release, when required (for
example, if the Account Lookup is pending on the target credit account, while Balance Inquiry on
the debit account already took place), or reverse posting, when required (for example, if the
Account Lookup is on the target credit account, while Posting on the debit leg already took place).
3.3.2 Inactive Queues
When the relevant interface is not active, GPP behaves according to the inactive behaviour set for
this interface, as per the generic interfaces functionality (for more details see GPP Interfaces
Technical Guide).
For the interfaces that are configured with Non-active behavior of STOP_UNTIL_ACTIVE or
PERMANAET_STOP, the inactive queues are where the transaction waits for the relevant interface to
become active.
3.3.2.1 Inactive CDB (CDBSTOP) Queue
If the Account Lookup interface Non-active behavior is setup as STOP_UNTIL_ACTIVE or
PERMANENT_STOP, when the interface goes down, the transaction is visible to the user in the
Inactive CDB (CDBSTOP) queue.
In this queue the user only has the action of Cancel.
GPP Processing:
The transaction is routed to cancellation flow, including earmark release, when required (for
example, if the Account Lookup cannot be performed on the target credit account, while Balance
Inquiry on the debit account already took place), or reverse posting, when required (for example,
if the Account Lookup cannot be performed on the target credit account, while Posting on the
debit leg already took place).
3.3.3 Manual Handling Queues
3.3.3.1 Posting Restrictions (POSTREST) Queue
A single transaction may be stopped in this queue following a negative Account Lookup response,
with posting restrictions/limitations on the account or the customer (meaning that a valid Stop Flag
existing in GPP is quoted as the reason for the failure).
In this queue the following actions can be performed:
Override: Instructs to override the restriction (only active for a message that was stopped due to
an overridable Stop Flag), and return the message to continue the processing.
GPP Processing:
- The relevant CDB monitor is set to P to allow skipping an additional invocation of the Account
lookup, when message is reprocessed.
GPP PAYplus | System Integration - Single Transactions | Page 15
- In addition, the MU_STOP_FLAGS_OVERRIDE_STS is set to O, to indicate that the posting
restriction was overridden, and processing continues from this point in the flow.
- Later in the flow, once reaching the points of Balance Check and Posting, these requests are
triggered and include the additional information of the user decision to override posting
restriction, either specifically quoting the MU_STOP_FLAGS_OVERRIDE_STS monitor as O,
or in the case of Posting request, providing a more general force indication for all posting
entries, which is relevant for both user actions of posting restriction override and force NSF (if
using the Standard Fndt Message is F_POSTING_INFO_FORCE_POST_IND=1).
Retry Post. Rest.: Instruct to retry the processing of the message
GPP Processing:
- Transaction is submitted back to try full reprocessing again, and invoking another attempt of
the Account lookup (for the relevant side which failed previously due to posting restrictions).
The transaction is routed to Wait CDB Response (CDBWAIT) pending response from HOST
system.
Send to Repair: Instructs GPP to send the message to the Repair (REPAIR) queue for manual
adjustments
GPP Processing:
- The transaction is routed to the Repair (REPAIR) queue.
Cancel: Instructs GPP to cancel the message
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required ((for
example, if the Account Lookup is on the target credit account, while Balance Inquiry on the
debit account already took place), or reverse posting, when required ((for example, if the
Account Lookup is on the target credit account, while Posting on the debit leg already took
place).
3.3.3.2 Repair Queue
A single transaction may be stopped in this queue, in relation with interfaces, following an Account
Lookup failure response with failure status that is not the specific Posting Restrictions, or due to
technical failure.
In this queue the following actions can be performed:
Make amendments to the transaction details and Submit it for re-processing.
GPP Processing:
- When reaching the point/s of Account lookup
If the relevant CDB monitor is not set to P, to indicate a successful Account Lookup, or if
relevant account was updated by the user, an additional invocation of the Account lookup
for the relevant account is triggered.
- When reaching the point of Balance Check
If the BI monitor is not set to P (i.e. either was stopped before or due to a Balance Inquiry
response), the Balance Inquiry interface is triggered.
If this monitor is P, to indicate a successful Balance Inquiry, but the Posting monitor
indicates failure, and if relevant transaction attributes were changed (account, amount,
value date), and if working in Earmark mode, an Earmark Release request along with the
new Balance Inquiry with earmark hold request are triggered, each quoting a new Event
ID.
- When reaching the point of Posting the Posting interface is triggered.
The Posting entries are re-calculated and compared with previous entries not already
marked as successful/reversed. I they are different (may happen when relevant
GPP PAYplus | System Integration - Single Transactions | Page 16
transaction attributes (account, amount, value date) were changed), reversed posting
entries are created for these non-final entries, along with the newly calculated entries.
These are included in the Posting request/s and are sent, quoting a new Event ID.
Cancel: Instructs GPP to cancel the message.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required (for
example, if the Account Lookup is on the target credit account, while Balance Inquiry on the
debit account already took place), or reverse posting, when required (for example, if the
Account Lookup is on the target credit account, while Posting on the debit leg already took
place).
Note: For the Account Lookup interface, the credit Account Lookup is performed on the account of the
party that is first in the credit chain (after the GPP chain enrichment). If the credit account was entered
manually, while in the Repair queue, and needs to be validated via Account Lookup, it must quote the
same first in chain account, as GPP does not take it into account for the credit Account Lookup.
3.3.4 Resume from Manual or Wait Statuses
Whenever a transaction is submitted to resume processing after being stopped in a manual or wait
statuses, and if the customer and account information were included in the Account Lookup
Response, these details are reloaded again from this Account Lookup Response (stored in
Processing Communications (MESSAGE_EXTERNAL_INTERACTION)). This allows their usage in
the payment processing.
3.4 Business Setup and System Configuration
3.4.1 Business Setup
3.4.1.1 System Parameters
These System Parameters are Business parameters, which are related to the Account Lookup
functionality, when it provide Stop Flags or limitations on the account or customer.
Name
Description
ASAP_POST_REST_CH
ECK
Specifies whether to perform the stop flags check as soon as possible.
Values:
Yes - Stop flags check is initially performed for debit and credit sides
separately as soon as the relevant account is loaded, either from
GPP or via Feeder Request. The final check for both sides is also
performed, in this case, on the later point in the flow (as performed if
the value is No).
No (default) - Consolidated stop flags check is performed for both
sides later in the flow, after MOP selection, STP override rules, Fee
calculation and Time Hold rules, but before sending future dated
transactions to Scheduled queue.
3.4.1.2 Profiles
These are the details of the required setup in GPP profiles for the Account Lookup Interface.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
3.4.1.2.1 Accounts Profile
If the financial institution requires keeping an entry representing an account in GPP, but still regards
the Master account entry as the entry managed in the external system, the External lookup check box
should be selected in the GPP Accounts entry. GPP then invokes the Account Lookup interface for
this account even though an entry exists for it in GPP.
GPP PAYplus | System Integration - Single Transactions | Page 17
3.4.1.2.2 Stop Flags Profile
The Stop Flag profile is relevant whenever the Account Lookup response may provide Stop Flags or
limitations on the account or customer.
Stop Flag entries should be defined in GPP for each Stop Flag value that may be provided as a
restriction in the Account Lookup response. Each of these Stop Flags may be set as overridable or as
non-overridable. In the Posting Restrictions queue the Override option is available for the user only if
the Stop Flag reported in the Account Lookup response is an overridable one. No such option is
available if the message was stopped due to a non-overridable Stop Flag.
3.4.1.3 Rules
3.4.1.3.1 Account Lookup Rules
Rules should be set to invoke the Account Lookup interface for the debit or credit account in cases
they belong to a customer (relevant side MOP is BOOK), and as per specific financial institution
business scenarios and conditions.
Note: These rules are invoked whenever a debit or credit account of a message is not found in GPP,
or is found but the External lookup check box is selected, indicating that the master copy for this
account resides in the financial institution’s external system.
3.4.1.4 Permissions
Permissions need to be granted to users that need to configure the different business profiles and
rules related to the Account Lookup interface.
3.4.2 System Configuration
3.4.2.1 System Parameters
There are no specific System Parameters, which are business parameters, required for the Account
Lookup Interface.
3.4.2.2 Profiles
These are the details of the required setup in GPP system profiles for the Account Lookup Interface.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
3.4.2.2.1 Interfaces
Relevant Interfaces entries should be configured for the Account Lookup interface (usually it is
required to set separate entries for the debit side and for the credit side). The timeout between retries
and the maximum number of retries should also be set in these entries according to the financial
institution’s requirements.
GPP should not continue processing the transaction until the account details are captured. It is
therefore recommended, that the Account Lookup interface Non-active behavior is setup as
STOP_UNTIL_ACTIVE with the Inactive queue as Inactive CDB (CDBSTOP).
For a description of the relevant fields, see the GPP Online Help or the GPP Interfaces Technical
Guide.
Note: When the Fndt Message format is defined as the structure to use for a specific interface type,
GPP can also be setup to control which sections of the generic Fndt Message structure are to be sent
out for this Request/Response, from a maximum with a full structure (including all the message
related attributes), to a minimum specific per interface type. For example for Account Lookup interface
only the sections quoting details of the account, customer and contacts.
GPP PAYplus | System Integration - Single Transactions | Page 18
3.4.2.3 Rules
3.4.2.3.1 Interface Selection
Interface Selection rules, selecting the relevant Interface Types entries, should be configured for the
Account Lookup interface request.
3.5 Message Data
There are no specific Message Attributes, errors and audit trails for this interface.
4 Balance Inquiry Interface
4.1 Overview
Balance checking is performed in GPP to determine whether the debit account on a transaction has
sufficient liquidity to allow the transaction to be released/completed.
The HOST system is responsible for:
Evaluating the account liquidity, which may include the account’s net balance as well as credit
lines and limits granted to the account. An account’s liquidity may also take into account the
balance of a group of accounts.
For placing a hold on the funds when a positive response is returned (if supported by HOST). The
response may provide current balance information for the account, and an earmark reference, if
hold was placed on the funds.
While GPP may receive an actual Balance value from the HOST, GPP allows the HOST system to
make the decision as to whether or not there is sufficient liquidity to release the transaction. The
HOST system is responsible for placing a hold on the customer’s funds (providing it includes support
for this type of hold) and when an approval is sent to GPP to release a transaction. It can be called in
a mode with an expectation that the HOST will place a hold on funds, or can be used in an ‘inquiry
only’ mode. This interface is always called within the context of a transaction.
Pending a response to the Balance Inquiry, and if the interface is working in A-sync mode, the
transaction is placed in Wait Balance Inq. Response (BIWAITQ) status.
Balance Inquiry response may be positive, negative or not final. Where the response is negative, it is
also possible to state the reason for failure. GPP is capable of setting the GPP message status (msg
sts) and where the transaction should park (whether it is Repair, Insufficient Funds, Posting
Restrictions or any pre-defined message status).
When the Balance Inquiry is done in the Balance Inquiry with Earmark mode, GPP provides support
for earmark release upon transaction cancellation or major change in the transaction details when
submitted after repair. The HOST system uses this request to un-earmark intraday the funds held at
the time of the Balance Inquiry from GPP.
GPP supports a GPP Standard Balance Inquiry format that is suggested to be used for this interface.
For more details on this format, see GPP Technical Guide - Fndt Message Usage for Balance Inquiry
Interface.
GPP can also support a proprietary format as per financial institution’s preference, once initial
mapping effort is included between the proprietary format and the GPP attributes, and as long as the
necessary information exists in this proprietary format.
4.2 Processing
4.2.1 Balance Check
GPP PAYplus | System Integration - Single Transactions | Page 19
4.2.1.1 Workflow
Start Balance
Inquiry step
Evaluate BI
Bypass rules
BI Bypass Rule
found?
Create balance
inquiry request
Continue HV
payment flow
Posting
restrictions?
Wait Behavior
BIWaitQ
Response
received
Successful
response?
No
(MI_BI_STS=N)
Posting
Restrictions
POSTREST
No
Repair
Yes
Yes
Yes
(MI_BI_STS=P)
Change
message details
and Submit
(might involve
invocation of
earmark release)
Canceled
Cancel
Override Post. Rest
(if stop flags is overridable)
(new EventID)
Copy and resend
original request
with a new delivery
timestamp
(same EventID)
Resend
from
MEI screen
Send to
Repair
Yes
Send to
Repair
Retry Post.Rest –
to resend with retry monitor
(new EventID)
‘Not Final’
response? No
Yes
No,
Failure
response
Insufficient
Funds?
Insufficient
Funds NSF
Yes
No
Retry NSF –
to resend with retry monitor
(new EventID)
Send to
Repair
Force NSF
Copy and resend
original request
with Force
indicator + a new
delivery timestamp
User Action
User Action
User Action
User Action
P_RETRY_COUNT<
MAXNSFRETRY?
Yes
Set
P_RELEASE_INDEX
and increment
P_RETRY_COUNT
No
Clear
P_RELEASE_INDEX
(auto retry will not be
performed anymore on
this payment)
No
GPP PAYplus | System Integration - Single Transactions | Page 20
4.2.1.2 Details
4.2.1.2.1 Handling Balance Inquiry Request
During payment processing, GPP makes Balance Inquiry calls in the context of an individual
transaction, which may be performed asynchronously or synchronously, as per the interface
configuration. This interface is not used by an operator performing an online Balance Inquiry on an
account.
The Balance Inquiry is performed on the debit account during the Analysis phase of processing. This
occurs after debit and credit account selection and validation, and more specifically after Fees
evaluation and before the external FX call.
The Balance Inquiry can be invoked in two modes:
Balance Inquiry with Earmark: HOST system checks the customer’s funds availability and, if funds
are sufficient, places a hold on the customer’s funds.
Inquiry Only: HOST system checks the account’s funds availability without placing a hold on the
funds.
Interface Selection rules are invoked to select the relevant Balance Inquiry interface.
GPP can include in the request a unique 16 character Event ID each time the transaction triggers the
Balance Inquiry interface (if using the GPP Standard Balance Inquiry format this ID is quoted in the
Event ID tag within the Header section):
When an automatic or manual Retry is performed (due to negative or late response), the request
is sent quoting a new event ID.
When it is a Force/Override request, the request is sent quoting a new Event ID.
When it is an Earmark Release, the request is sent quoting a new Event ID.
When it is a Resend, the request is sent quoting the original Event ID.
The event ID is stored in the Message external interaction (EVENT_ID column), for interfaces that are
configured to create a MESSAGE_EXTERNAL_INTERACTION entry, and the
EVENT_ID_GENERATION field is set to 1 in their INTERFACE_TYPES entry. It is generated with the
algorithm being similar to MID generation, including letters, numbers, and date & time, and it is saved,
and can be used, in the D_MEI_EVENT_ID Logical Field.
GPP stores the response in the Processing Communications
(MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct so.
Once a request is built, GPP sends it to the HOST, and the transaction is routed, when interface is A-
sync, to the Wait Balance Inq. Response (BIWAITQ) status.
4.2.1.2.2 Handling Balance Inquiry Response
The HOST system should determine, based on the account number and the amount and date of the
transaction, whether or not to respond with:
A successful response which is ‘make the transaction’; OR
A failure response which is ‘do not make the transaction’; OR
A non-final response
GPP PAYplus | System Integration - Single Transactions | Page 21
Once a response is received in GPP:
GPP parses the response.
GPP validates that the response contains the required information and is structurally valid against
the relevant defined structure, either the Standard Fndt Message or a financial institution specific
proprietary structure per this interface type.
GPP performs matching between the response and the relevant request. For more details on the
matching functionality see Response/Request Matching.
GPP stores the response in the Processing Communications
(MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct
so.
Audit trail of the transaction is updated to indicate that a response was received. For a negative
response, a response error description is also added to the message error log.
GPP evaluates the response value to decide to where it should route the transaction. See details
in Successful Response, Non-Final Response, and Failure Response.
If the response is not received within a configurable timeout period, timeout will be retried per
configured number of retries on the Interface Type, after which - Interface becomes inactive and
Balance Inquiry request is treated as failed. For more details on Interface Timeout behavior, see
GPP Technical Guide - Interfaces document
4.2.1.2.2.1 Successful Response
A successful response is received (if using the Standard Fndt Message <returnCode>=1),
meaning there is sufficient liquidity in the principal account to send the transaction.
GPP continues with processing of the message.
If additional information (earmark reference and/or balance) is provided in the Balance Inquiry
response, GPP stores the information in the transaction data.
Later in the processing, while performing the posting step, if earmark reference was returned in
the Balance Inquiry response, meaning hold was placed on the customer funds for this
transaction, GPP uses it and returns it to the HOST system as part of the Posting request.
MI_BI_STS is set to P to indicate a successful balance check.
4.2.1.2.2.2 Non-Final Response
A non-final response is received (if using the Standard Fndt Message <returnCode>=200),
meaning that the request was received in the HOST system but additional investigations/manual
handling in this system are required and therefore a final response will be sent later. Another
reason for such a response might be that there are insufficient funds to send the transaction at
the current time and the HOST is going to continue to wait for funding.
- This type of response is used for an interface which is defined with a time out mechanism, in
order to avoid reaching the maximum time out retries.
- GPP is expecting the HOST to eventually send either a Failed or a Successful response.
- GPP leaves the message in the Wait Balance Inq. Response (BIWAITQ) queue.
- Interface time out counter is set to zero.
4.2.1.2.2.3 Failure Response
The following responses are the options for failure response (if using the Standard Fndt Message
<returnCode> is not 1 or 200):
- Processing Error Response:
The HOST is unable to derive the requested account information due to a technical error.
The Response is returned to GPP with a processing error response reason code and
description of error. GPP routes the transaction to the Repair (REPAIR) queue
GPP PAYplus | System Integration - Single Transactions | Page 22
- Functional Failure Response - either of the following:
The HOST is unable to perform balance check because the account does not exist. The
response is returned to GPP with a functional failure response reason code and
description. GPP routes the transaction to a Repair (REPAIR) queue.
The HOST finds the account, but the account has posting restrictions on it. The HOST
may return additional details about the specific posting restriction codes and description.
GPP routes the transaction to the Posting Restrictions (POSTREST) queue.
The HOST finds the account, but the account has insufficient liquidity to make the
transaction. GPP routes the transaction to the Insufficient Funds (NSF) queue.
o In this case GPP already prepares the transaction to an automatic retry, if not already
breaching the maximum retries, by incrementing an attribute that counts the retries
(P_RETRY_COUNT) and calculating the index attribute that will be used to select the
transactions waiting for such retry, with the next time per the pre-configured
frequency of retries. For more details see Automatic Retries.
- For any of the failure responses:
MI_BI_STS is set to N to indicate a non-successful balance check.
GPP PAYplus | System Integration - Single Transactions | Page 23
4.2.2 Earmark Release
4.2.2.1 Earmark Release Workflow
Yes
Create earmark
release request
Continue flow
HV flow
Response
received
Yes
No
Successful
response?
Follow Up flag set
to
NEG_BI_RSPNS_A
FTR_RLS
Change
message details
and Submit
User Action
(from
Repair
queue)
Check threshold of
Debit Amount
change
Major details
changed?
No
Yes
More than
accepted? No
User Action
(from any
queue)
Cancel
Yes
Earmark
previously
placed?
No
Continue
Cancelation flow
4.2.2.2 Details
4.2.2.2.1 Handling Earmark Release Request
When the Balance Inquiry is done in the Balance Inquiry with Earmark mode, GPP provides support
for earmark release during transaction cancellation flow, or if major transaction details were changed
as part of its repair.
In a scenario, where a transaction is cancelled or changed in GPP after a successful balance
response is received from HOST, and only when using the model of HOST placing a hold on the
customer funds for this transaction (Balance Inquiry is done in the Balance Inquiry with Earmark
mode), GPP can be configured to send an additional interface call in the Earmark Release mode.
Earmark release is also triggered in cases where there are delivery failures on the outbound
messages, for example, FED/CHIPS/SWIFT rejects.
The earmark release is invoked
GPP PAYplus | System Integration - Single Transactions | Page 24
When a successful earmark hold response, quoting an Earmark Reference, was previously
received, but posting for this amount is not yet performed.
Notes:
When the earmark hold response was previously negative, no earmark release is required
When a successful response of Earmark mode was previously received, but no Earmark Reference
was quoted in it – GPP regards this response as a BI response and no earmark release is required.
The interface selection rule which selects Earmark Release should be configured based on the flow
context (cancelation/reject and the P_BI_MAIN_ERAMARK_REF in which the previously received
Earmark Reference, if received, is quoted.
The Earmark Release interface generates a request to the HOST system, quoting a new event ID and
the previously received earmark reference (populated from the P_BI_MAIN_ERAMARK_REF or
P_BI_FEE_ERAMARK_REF depending on the type of amount that was held and needs releasing (if
using the Standard Fndt Message this is passed in the F_BI_INFO_EARMARK_REF tag).
GPP stores the response in the Processing Communications
(MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct so.
The transaction does not park in a wait queue after sending the earmark release request.
When a negative response is received, the Follow up flag is updated on the transaction entry with the
value NEG_BI_RSPNS_AFTR_RLS. This Follow up flag can be used in a Custom filter rule to allow
viewing the transaction in a separate Custom queue for monitoring.
When a transaction is routed to Repair/Wait queue after Balance Inquiry, GPP triggers the Balance
Inquiry when the transaction is released from the queue and submitted back to the high value flow. If
relevant transaction attributes were changed (account, amount, and value date), an earmark release
request and a new earmark hold request are sent, each quoting new Event IDs.
Note: A threshold is defined by which GPP should re-invoke the Balance Inquiry check. The threshold
is defined in the Interface profile as a percentage. For example, threshold is defined as 10% and
original check done on the amount of 100. If the new amount is up to 110 then re-invocation is not
required.
4.2.2.2.2 Handling Earmark Release Response
GPP parses the response.
GPP validates the response is structurally valid, against the relevant defined structure – either the
Standard Fndt Message or a financial institution specific proprietary structure per this interface
type, and contains the required information.
GPP performs matching between the response and the relevant request. For more details on the
matching functionality see Response/Request Matching.
GPP stores the response in the Processing Communications
(MESSAGE_EXTERNAL_INTERACTION table), when the Interface entry is configured to instruct
so.
As the transaction was not waiting for the Earmark Release response, there is no special
handling, but logging its arrival on the transaction level is performed, on either successful or
failure responses.
4.2.3 Automatic Retries
Automatic retries are not performed for all types of interfaces. This section describe the automatic
retries which are supported for the Balance Inquiry interface.
GPP PAYplus | System Integration - Single Transactions | Page 25
NSF event
(frequency as per
NSF_CHECK_FREQ
Gather transactions
with
P_RELEASE_INDEX
=NSF^HH:MM (as per
EVENET_ACTIVITIES
record)
Submit to the High
Value flow
When the message is in Insufficient Funds (NSF) queue (after an NSF response), GPP supports the
functionality of limited automatic retries.
The process is as follows:
The automatic triggering is based on a pre-defined frequency (usually set to 5 - 15 seconds), that
is configured in the NSF_CHECK_FREQ system parameter.
When reaching the maximum number of retries, as pre-defined in the MAXNSFRETRY system
parameter, GPP logs an error in the transaction’s error log, and the transaction remains in
Insufficient Funds (NSF) queue.
Notes:
When a manual retry is performed using the Retry Insf. Funds button, before GPP stops its
automatic retries (before MAXNSFRETRY number of retries), this retry is included in the count of
retries before stopping.
The counting of retries is not interrupted or re-started in a scenario when the Business Date
changes between retries. This means that if the maximum number of retries is 5, and after 3 retry
attempts, all are still resulting in NSF responses, and the Business Date was advanced, GPP
continues to retry only two more times before reaching the maximum and stopping the retries.
GPP supports the functionality of limited automatic retries of the same request when the message is
in Wait Balance Inq. Response (BIWAITQ) queue (waiting for a Balance Inquiry response), and the
Balance Inquiry interface is configured to do so.
Note: When configured as Balance With Earmark it is recommended to not configure the interface
with automatic retries.
4.2.4 Response/Request Matching
In general, on Request/Response interfaces GPP supports matching methods (some functional and
some technical) between the request, sent from GPP, and the response, received from the external
financial institution system.
The functional, and more generic, method is the usage of <ContecName> and
<contexLocalName>, quoting, in the response, their value/s from the request + the P_MID.
There are additional technical methods that allow echo back of the sending system (for example,
GPP or a HOST channel) identifier in a custom property of the MQ header (the value of this
identifier is captured from the request as transport property) or using the MQ correlation Id in the
MQ envelope.
Note: The Event ID is not currently used in the matching, therefore it is not mandatory to be returned
in the response.
4.3 Manual Handling
This section describes the various scenarios in which a single transaction may be stopped in relation
with the Balance Inquiry interface.
In a wait queue until the relevant response is received, or
In an inactive queue until the interface is active again, or
A manual queue due to information received in the response
GPP PAYplus | System Integration - Single Transactions | Page 26
The description is per such specific manual queues. For a summary of actions per queue, see
Appendix A: Manual Actions per Queues.
4.3.1 Wait Queues
4.3.1.1 Wait Balance Inq. Response (BIWAITQ) Queue
A single transaction is stopped in this queue after an A-sync Balance Inquiry request is sent to the
external system, and until a Balance Inquiry response is received. When using sync mode the
process is not stopped but waits for an online response, and the transaction is not parked in any
queue.
In this queue the following actions can be performed:
Force: Instructs GPP to continue processing even though no response was received. Only
entitled users whose user profile maximum force limit amount is greater than the message
amount can use this action button.
GPP Processing:
Transaction is released back to continue processing. Retry Bal. Inq.: Instructs GPP to retry the
processing of the message
GPP Processing:
- The CDB monitor is kept as P, if external Account Lookup is required and was performed
earlier in the flow, to allow skipping an additional invocation of the Account lookup, when
message is reprocessed.
- When reaching the relevant point in the flow for Balance inquiry, and as the Balance Inquiry
monitor is not set to P, as an indication that this step already ended successfully, GPP
generates a new Balance Inquiry request to the HOST system, quoting a new event ID. The
transaction is routed to Wait Balance Inq. (BIWAITQ) pending response from HOST system.
Send to Repair: Instructs GPP to send the message to the Repair (REPAIR) queue for manual
adjustments
GPP Processing:
- The transaction is routed to the Repair (REPAIR) queue.
Cancel: Instructs GPP to cancel the message
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, and
reverse posting, when required (for example, if the Balance Inquiry is pending on the second
leg (target debit account), and Posting was already performed on first leg).
4.3.2 Inactive Queues
When the relevant interface is not active, GPP behaves according to the inactive behaviour set for
this interface, as per the generic interfaces functionality (for more details see GPP Interfaces
Technical Guide).
For the interfaces that are configured with Non-active behavior of STOP_UNTIL_ACTIVE or
PERMANAET_STOP, the inactive queues are where the transaction waits for the relevant interface to
become active.
4.3.2.1 Inactive BI (BI_STOP) Queue
The Balance Inquiry is a way to stop a transaction earlier than when need to perform the actual
Posting. It is therefore recommended, that the Balance inquiry interface is configured with the Non-
active behavior of SKIP, so that, GPP can proceed with the processing without checking the balance
when the interface is not active.
GPP PAYplus | System Integration - Single Transactions | Page 27
If the financial institution still wants to stop the transaction at the Balance Inquiry step and wait until it
is active, the interface can be configured with Non-active behavior of STOP_UNTIL_ACTIVE. In this
case when the interface is down the transaction is visible to the user in the Inactive BI (BI_STOP)
queue.
If Non-active behavior is set to PERMANENT_STOP, after the interface becomes inactive, and even if
gets active again, the transaction remains visible to the user in the Inactive BI (BI_STOP) queue.
In this queue the user only has the action of Cancel.
GPP Processing:
The transaction is routed to cancellation flow, including earmark release, when required, and
reverse posting, when required (for example, if the Balance Inquiry cannot be performed on the
second leg (target debit account), and Posting was already performed on first leg).
4.3.3 Manual Handling Queues
4.3.3.1 Posting Restrictions (POSTREST) Queue
A single transaction may be stopped in this queue following a negative Balance Inquiry response with
posting restrictions/limitations on the account or the customer (meaning that a valid Stop Flag existing
in GPP is quoted as the reason for the failure).
In this queue the following actions can be performed:
Override: Instructs to override the restriction (only active for a message that was stopped due to
an overridable Stop Flag), and return the message to continue the processing.
GPP Processing:
- The relevant CDB monitor is kept as P, if external Account Lookup is required and was
performed earlier in the flow for this account, to allow skipping an additional invocation of the
Account lookup, when message is reprocessed.
- The MU_STOP_FLAGS_OVERRIDE_STS is set to O, to indicate that the posting restriction
was overridden, and processing continues from this point in the flow.
- When reaching again the point of Balance Check, but only if the BI monitor is not P (it can be
P if the transaction was routed to this queue later in the flow due to a Posting response),
Balance inquiry interface generates a new request to the HOST system, quoting a new event
ID, and indicating that the restriction was overridden (if using the Standard Fndt Message -
MU_STOP_FLAGS_OVERRIDE_STS = O is quoted in the added Monitors extension). In
Balance Inquiry with Earmark mode, the transaction is routed to Wait Balance Inq. Response
(BIWAITQ) pending response from HOST system.
- Later in the flow, once reaching the point of Posting – this request includes the additional
information of the user decision to override posting restriction, either specifically quoting the
MU_STOP_FLAGS_OVERRIDE_STS monitor as O, or providing a more general force
indication, for all posting entries, which is relevant for both user actions of posting restriction
override and force NSF (if using the Standard Fndt Message -
F_POSTING_INFO_FORCE_POST_IND=1).
Retry Post. Rest.: Instruct to retry the processing of the message
GPP Processing:
- The CDB monitor is kept as P, if external Account Lookup is required and was performed
earlier in the flow, to allow skipping an additional invocation of the Account lookup, when
message is reprocessed.
- When reaching again the point of Balance Check, but only if the BI monitor is not P (it can be
P if the transaction was routed to this queue later in the flow due to a Posting response),
Balance inquiry interface generates a new request to the HOST system, quoting a new event
GPP PAYplus | System Integration - Single Transactions | Page 28
ID. The transaction is routed to Wait Balance Inq. (BIWAITQ) pending response from HOST
system.
Send to Repair: Instructs GPP to send the message to the Repair (REPAIR) queue for manual
adjustments
GPP Processing:
- The transaction is routed to the Repair (REPAIR) queue.
Cancel: Instructs GPP to cancel the message
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, and
reverse posting, when required (if the Balance Inquiry failed on the second leg (target debit
account), and Posting was already performed on first leg).
4.3.3.2 Insufficient Funds (NSF) Queue
A single transaction may be stopped in this queue following a negative Balance Inquiry response with
an indication of no sufficient funds in the account.
In this queue the following actions can be performed:
Force Ins. Funds: Instructs GPP to continue processing even though the debit account has
insufficient funds. Only entitled users whose user profile maximum force limit amount is greater
than the message amount can use this action button.
GPP Processing:
- Balance inquiry interface generates a new request to the HOST system, quoting a new event
ID, and indicating that the user allows transaction processing to continue even though the
account has insufficient funds (if using the Standard Fndt Message - MU_NSF_FORCE_STS
= 1 within the added Monitors extension). In Balance Inquiry with Earmark mode, the
transaction is routed to Wait Balance Inq. Response (BIWAITQ) pending response from
HOST system.
- Later in the flow, once reaching the point of Posting, this request includes the additional
information of the user decision to force the processing even with no sufficient funds in the
account. Either specifically quoting the MU_NSF_FORCE_STS monitor as 1, or providing a
more general force indication, for all posting entries, which is relevant for both user actions of
posting restriction override and force NSF (if using the Standard Fndt Message
F_POSTING_INFO_FORCE_POST_IND=1).
Retry Ins. Funds: Instructs GPP to perform the Balance Inquiry interface call again.
GPP Processing:
- Transaction is submitted back to try reprocessing again, eventually triggering another
invocation of Balance Inquiry. Interface generates a new request to the HOST system,
quoting a new Event ID. The transaction is routed to Wait Balance Inq. (BIWAITQ) pending
response from HOST system.
Send to Repair: Instructs GPP to send the message to the Repair (REPAIR) queue for manual
adjustments
GPP Processing:
- The transaction is routed to the Repair (REPAIR) queue.
Cancel: Instructs GPP to cancel the message.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required,
reverse posting, when required (if the Balance Inquiry failed on the second leg (target debit
account), and Posting was already performed on first leg).
GPP PAYplus | System Integration - Single Transactions | Page 29
4.3.3.3 Repair Queue
A single transaction may be stopped in this queue, in relation with interfaces, following a Balance
Inquiry response with failure status that is not one of the specific Posting Restrictions or Insufficient
Funds, or due to technical failures handling any of interfaces’ responses.
In this queue the following actions can be performed:
Make amendments to the transaction details and Submit it for re-processing.
GPP Processing:
- When reaching the point/s of Account Lookup
If the relevant CDB monitor is not set to P, to indicate a successful Account Lookup, or if
the relevant account was updated by the user, an additional invocation of the Account
lookup for the relevant account is triggered.
- When reaching the point of Balance Check
If the BI monitor is not set to P (meaning that it was stopped before or due to a Balance
Inquiry response), the Balance Inquiry interface is triggered.
If this monitor is P, to indicate a successful Balance Inquiry, but the Posting monitor
indicates failure, and if relevant transaction attributes were changed (account, amount,
value date), and if working in Earmark mode, an Earmark Release request along with the
new Balance Inquiry with earmark hold request are triggered, each quoting a new event
ID.
- When reaching the point of Posting the Posting interface is triggered.
The Posting entries are re-calculated and compared with previous entries not already
marked as successful/reversed. I they are different (may happen when relevant
transaction attributes (account, amount, value date) were changed), reversed posting
entries are created for these non-final entries, along with the newly calculated entries.
These are included in the Posting request/s and are sent, quoting a new Event ID.
Cancel: Instructs GPP to cancel the message.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, or
reverse posting, when required (if the Balance Inquiry failed on the second leg (target debit
account), and Posting was already performed on first leg).
Note: The Account Lookup on the credit account is performed on the account of the party that is first
in the credit chain (after the GPP chain enrichment). If the Credit account was entered manually, while
in the Repair queue, and needs to be validated via Account Lookup, it must quote the same first in
chain account, as GPP does not take it into account for the credit Account Lookup.
4.4 Business Setup and System Configuration
4.4.1 Business Setup
4.4.1.1 System Parameters
These System Parameters are Business parameters, which are related to the Balance Inquiry
functionality, when it provides Stop Flags or limitations on the account or customer.
Name
Description
ASAP_POST_REST_CH
ECK
Specifies whether to perform the stop flags check as soon as possible.
Values:
Yes - stop flags check is initially performed for debit and credit sides
separately as soon as the relevant account is loaded, either from
GPP or via Feeder Request. The final check for both sides is also
GPP PAYplus | System Integration - Single Transactions | Page 30
Name
Description
performed, in this case, on the later point in the flow (as performed if
the value is No).
No - consolidated stop flags check is performed for both sides later in
the flow, after MOP selection, STP override rules, Fee calculation
and Time Hold rules, but before sending future dated transactions to
Scheduled queue. Default
MAXNSFRETRY
Defines the maximum count for insufficient funds check retries. After
which an automated retry is not performed.
NSF_CHECK_FREQ
Specifies the frequency, in milliseconds, that transaction in the
Insufficient Funds (NSF) status re-checked.
The frequency should not be less than the NSF task frequency as
depicted in the EVENT_DEFINITION.FREQUENCY_IN_MINUTES
column.
Example: 300,000 milliseconds equal to 5 minutes
4.4.1.2 Profiles
These are the details of the required setup in GPP profiles for the Balance Inquiry Interface.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
4.4.1.2.1 Stop Flags
The Stop Flag profile is relevant whenever the Balance Inquiry response may provide Stop Flags or
limitations on the account or customer.
Stop Flag entries should be defined in GPP for each Stop Flag value that may be provided as a
restriction in the Balance Inquiry response. Each of these Stop Flags may be set as overridable or as
non-overridable. In the Posting Restrictions queue the Override option is available for the user only if
the Stop Flag reported in the Balance Inquiry response is an overridable one. No such option is
available if the message was stopped due to a non-overridable Stop Flag.
4.4.1.2.2 User Codes
Reason Type
Reason Code
Reason Description
FOLLOWUP
NEG_BI_RSPNS_AFTR_RLS
Negative response received on earmark release
during transaction cancellation
4.4.1.3 Rules
4.4.1.3.1 Bypass Step Rules
Bypass step with the sub type of Balance Inquiry may be set to bypass the invocation of the Balance
Inquiry interface for scenarios when this check is not required as per specific financial institution
requirements. For example, when the position of the debit account is managed in GPP (the Accounts
entry exists and it is marked as Posting Keeping).
4.4.1.4 Permissions
Permissions need to be granted to users that need to configure the different business profiles and
rules related to the Balance Inquiry interface.
GPP PAYplus | System Integration - Single Transactions | Page 31
4.4.2 System Configuration
4.4.2.1 System Parameters
There are no specific System Parameters, which are business parameters, required for the Balance
Inquiry Interface.
4.4.2.2 Profiles
These are the details of the required setup in GPP system profiles for the Balance Inquiry Interface.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
4.4.2.2.1 Interfaces
Relevant Interfaces entries should be configured for the Balance Inquiry interface request and
response.
Balance Inquiry may be configured as a synchronous or an asynchronous interface (Wait
behavior). For the a-synchronous mode only, the wait queue Wait Balance Inq. Response
(BIWAITQ) is specified.
In both cases, an inactive behavior (SKIP, STOP_UNTIL_ACTIVE, PERMANENT_STOP or
STORE) is defined.
- As the Balance Inquiry is just a way to stop a transaction earlier than when need to perform
the actual Posting, it is recommended that the Balance inquiry interface is configured with the
non-active behaviour of SKIP, so that, GPP can proceed with the processing without checking
the balance when the interface is not active.
- If the financial institution still wants to stop the transaction at the Balance Inquiry step, the
interface can be configured with non-active behaviour set to STOP_UNTIL_ACTIVE or
PERMANENT_STOP, and Inactivity Status set to Inactive BI (BI_STOP) queue.
The context keyword in the Custom Properties of Interface Type entries of Outgoing requests
should contain the value to send in the <ContextName> tag of the request message:
- BalanceInquiry, BalanceInquiry_With_Earmark– are the options for the Balance Inquiry
Interfaces entry. BalanceInquiry_With_Earmark is the default Product setup, but this
parameter can be configured to BalanceInquiry per deployment for banks which their account
balancing management system does not support earmarking.
- EarmarkRelease – for the Interfaces entry of Earmark Release.
Additional technical definitions, for example, the connection point of the MQ queue used.
For a description of the relevant fields, see the GPP Online Help or the GPP Interfaces Technical
Guide.
Note: When the Fndt Message format is defined as the structure to use for a specific interface type,
GPP can also be setup to control which sections of the generic Fndt Message structure are to be sent
out for this Request/Response, from a maximum with a full structure (including all the message
related attributes), to a minimum specific per interface type. For example for Balance Inquiry interface
only the section quoting the balance check information.
4.4.2.2.2 Event Management
The event NSF should be set for the automated retry task.
Event Name
Event Description
Mode
Minutes
Batch Size
NSF
Automatic Retry of NSF
messages
0
10
The frequency of the
task should be equal
to or less than the
1
GPP PAYplus | System Integration - Single Transactions | Page 32
Event Name
Event Description
Mode
Minutes
Batch Size
setting of the
NSF_CHECK_FREQ
system parameter
4.4.2.3 System Rules
4.4.2.3.1 Interface Selection
Interface selection rules can be configured according to customer’s requirement, in order to select the
relevant Balance Inquiry interface (Balance Inquiry with Earmark or Inquiry Only, and the Earmark
Release scenario).
4.5 Message Data
There are no specific Message Attributes, errors and audit trails for this interface.
5 Compliance Interface
5.1 Overview
Compliance with the laws, rules and standards that govern banking activities helps maintain a
financial institution’s reputation with its shareholders, customers, employees and the investment
community.
Compliance laws, rules and standards include the prevention of money laundering and terrorist
financing. A financial institution that knowingly participates in transactions intended by customers to
avoid regulatory or financial reporting requirements, evade tax liabilities or facilitate illegal conduct
exposes itself to serious compliance risk.
The Office of Foreign Assets Control (OFAC) administers and enforces sanctions against countries
and groups of individuals, such as terrorists and narcotics traffickers. These sanctions include the
blocking of assets and trade restrictions to accomplish foreign policy and national security goals.
GPP supports the compliance interface, which enhances a financial institution’s ability to implement
the requirements of OFAC and similar regulatory bodies in other countries.
GPP PAYplus | System Integration - Single Transactions | Page 33
5.2 Processing
5.2.1 Workflow
User Action
Sanctions Flow
SWIFT/Clearing/
CREATE GPP Interface External Sanctions System
Payment
Processing
First Response
External Sanctions
System
WAIT_OFAC
OFAC_POSSIB
LE_HIT
Continue
Processing
No Hit
Hit
Response Type
Resend
Cancellation
Flow
Cancel
Second Response
No Hit
Approved
Cancel
(Outgoing)
Return
(Incoming)
Continue
Processing
User Action
Response Type
Return Flow
OFAC_HIT
Send to Repair
Failure/Invalid
Force
User Action
REPAIR
REPAIR
Format Request
Payment
Seized
Failure/Invalid Seized Funds
5.2.2 Details
The Compliance interface in GPP triggers a call to an external system for transactions to be screened
against current Sanction and Compliance lists.
The Compliance interface can be triggered at two points in the single payment flow:
Predebit - Prior to debit side derivation
Preposting - Prior to the Posting invocation point, which is before completion of the incoming
transaction or sending out of outgoing transaction.
GPP PAYplus | System Integration - Single Transactions | Page 34
In general, the predebit point is used for incoming transactions and the preposting point for outgoing
transactions. Incoming and Onward transactions trigger the Compliance check at both points.
1. GPP invokes the Compliance validation business rule in order to determine whether a transaction
should be sent to Compliance check.
- Rule action is derived from a pre-defined field value (where Field type is
COMPLIANCE_CHECK).
- Rule action can be set as BYPASS, indicating this transaction should bypass the Compliance
check.
2. GPP invokes the Interface selection rule to apply the relevant interface.
3. GPP generates the Compliance request, which can use the proprietary customer specific
structure, or the standard Fndt Message structure, and routes the transaction to Wait OFAC
queue, pending a response.
4. When the initial response is received, GPP evaluates the return code provided in the response:
- Return code is No Hit: The transaction passed the screening with no hit. The transaction
continues to be processed.
- Return code is Possible Hit: The transaction had a possible hit and is under investigation
within the external Compliance system. GPP routes the transaction to OFAC Possible Hit
queue with the relevant error. The transaction waits in this queue pending a second response.
5. When the second response is received, GPP evaluates the return code provided in the response:
- Return code is No Hit: The transaction continues to be processed.
- Return code is Hit: GPP routes the transaction to the Compex queue.
- Return code is Seized Funds: GPP changes automatically the Credit account to a special
suspense seizing account- either the default Seize account configured in the Currency profile,
or another selected later on in the flow through the Destination Account selection rules,
changes the MOP to BOOK, processes the transaction, including the Posting (funds taken
into the suspense account), and finally routes the transaction to the Seized queue,
6. If the response is not received within a configurable timeout period, timeout will be retried per
configured number of retries on the Interface Type, after which - Interface becomes inactive and
Compliance request is treated as failed. For more details on Interface Timeout behavior, see GPP
Technical Guide - Interfaces document
5.2.3 Response/Request Matching
In general, on Request/Response interfaces GPP supports matching methods (some functional and
some technical) between the request, sent from GPP, and the response, received from the external
financial institution system.
The functional, and more generic, method is the usage of <ContecName> and
<contexLocalName>, quoting, in the response, their value/s from the request + the P_MID.
There are additional technical methods that allow echo back of the sending system (for example,
GPP or a HOST channel) identifier in a custom property of the MQ header (the value of this
identifier is captured from the request as transport property) or using the MQ correlation Id in the
MQ envelope.
Note: The Event ID is not currently used in the matching, therefore it is not mandatory to be returned
in the response.
5.3 Manual Handling
This section describes the various scenarios in which a single transaction may be stopped in relation
with the Compliance interface.
GPP PAYplus | System Integration - Single Transactions | Page 35
5.3.1 Wait Queues
5.3.1.1 Wait OFAC Queue (WAIT_OFAC)
A single transaction is stopped in this queue when it is waiting for an initial response from the
Compliance interface.
In this queue the following actions can be performed:
Processing Communications: Opens the Processing Communications page to allow instructing to
resend the interface request.
GPP Processing:
- The Processing Communications page is opened for the user to resend the interface request,
quoting the same event ID (if exists).
Force: Instructs GPP to continue processing the transaction as if no hit was detected.
GPP Processing:
- The transaction is processed as if a no hit response is received.
Reject/Return: Opens a new transaction page in order to create a related Outgoing Return
transaction. This is relevant for Incoming transactions only.
GPP Processing:
- GPP opens a new transaction page for users to input required data and submit. The outgoing
return is processed to completion to be sent out. When return is in Complete, original
transaction is routed to Returned queue.
Send to Repair: Instructs GPP to send the transaction to the Repair (REPAIR) queue for manual
adjustments
GPP Processing:
- The transaction is routed to the Repair (REPAIR) queue.
Cancel: Instructs GPP to cancel the transaction. This is relevant for outgoing transactions only.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, and
reverse posting, when required.
5.3.2 Manual Handling Queues
5.3.2.1 OFAC Possible Hit Queue (OFAC_POSSIBLE_HIT)
A single transaction is stopped in this queue when the transaction received a Hit in the initial response
from the Compliance interface.
In this queue the following actions can be performed:
Force: Declines the Possible Hit and instructs GPP to continue processing the transaction as if no
hit was detected.
GPP Processing:
- The transaction is processed as if a no hit response is received.
Cancel: Instructs GPP to cancel the transaction. This is relevant for outgoing transactions only.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, and
reverse posting, when required.
GPP PAYplus | System Integration - Single Transactions | Page 36
5.3.2.2 Compex Queue (COMPEX)
A single transaction is routed from OFAC Possible Hit queue to this queue when a transaction
received a Hit in the second response from the Compliance interface.
In this queue the following actions can be performed:
Reject/Return: Opens a new transaction page in order to create a related Outgoing Return
transaction. This is relevant for Incoming transactions only.
GPP Processing:
- A new transaction page is opened for users to input required data and submit. The outgoing
return is processed to completion to be sent out. When return is in Complete, original
transaction is routed to Returned queue.
Send to Repair: Instructs GPP to send the transaction to the Repair (REPAIR) queue for manual
adjustments. If required, the original credit account can be manually replaced with a suspense
account.
GPP Processing:
- The transaction is routed to the Repair (REPAIR) queue.
Cancel: Instructs GPP to cancel the transaction. This is relevant for outgoing transactions only.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, and
reverse posting, when required.
5.3.2.3 Repair Queue (REPAIR)
A single transaction may be stopped in this queue, when receiving a Processing/Technical error in the
second response from the Compliance interface.
In this queue the following actions can be performed:
Make amendments to the transaction details and Submit it for re-processing.
GPP Processing:
- To replace the Credit Account with a Suspense Account for seizing the funds
Change the credit account to the account where the blocked funds need to be
transferred.
Change the Credit MOP to BOOK.
Submit the transaction.
Cancel: Instructs GPP to cancel the transaction. This is relevant for outgoing transactions only.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, or
reverse posting, when required.
5.4 Business Setup and System Configuration
5.4.1 Business Setup
5.4.1.1 System Parameters
There are no specific System Parameters, which are business parameters, required for the
Compliance Interface.
GPP PAYplus | System Integration - Single Transactions | Page 37
5.4.1.2 Profiles
5.4.1.2.1 Currency Profile
The Seized Funds Suspense Account field is used to define the default credit account to be used
when a Compliance response of Hit and Seize (return code 2) was received, or the user used the
Block button in the Compliance Exception queue. This account may later in the flow be overridden by
the Destination Account Enrichment rule.
Note: For a detailed description of all the profiles, see GPP Online Help.
5.4.1.3 Rules
5.4.1.3.1 Compliance Validation Rule
This business rule defines at which exit point the system triggers the compliance check for a
transaction.
The recommended setup is to use the predebit point for incoming transactions and the preposting
point for outgoing transactions. Incoming and Onward transactions trigger the Compliance check at
both points.
The business rule should be based on the transaction direction (Debit/Credit MOPs) and the OFAC
interface monitors; OFAC Predebit status and OFAC Preposting status.
This is an example of the rule setup. The final setup should be done by the Financial Institution.
Rule Attribute
Setup Guidelines
Rule Name
COMPLIANCE_PREDEBIT
Rule Sub Type (Relation Type)
0
Description
Rule to trigger the PREDEBIT compliance check (incoming and
onward transactions)
Attachment
***
Rule conditions
[Dbt MOP] <> BOOK
And [OFAC Predebit sts] = P
Rule Action
SANCTIONS
Rule Attribute
Setup Guidelines
Rule Name
COMPLIANCE_PREPOSTING
Rule Sub Type (Relation Type)
0
Description
Rule to trigger the PREPOSTING compliance check (outgoing
and onward transactions)
Attachment
***
Rule conditions
[Cdt MOP]<> BOOK
And [OFAC Preposting sts] = P
Rule Action
SANCTIONS
GPP PAYplus | System Integration - Single Transactions | Page 38
Form this scenario and example the following Compliance Bypass rule should be attached at a lower
hierarchy than the Compliance Predebit and Compliance Preposting rules, in order that it is applied if
neither of the two were applied.
Rule Attribute
Setup Guidelines
Rule Name
COMPLIANCE_BYPASS
Rule Sub Type (Relation Type)
0
Description
Rule to bypass compliance
Attachment
***
Rule conditions
Rule Action
BYPASS
5.4.1.3.2 Destination Account Enrichment Rule
This business rule allows overriding the default Seize funds. Suspense account configured in the
Currency profile for a case funds need to be seized, when the transaction continues the flow till
completion.
The business rule should be based on the Monitor indicating the instruction for seizing
(MU_COMPLIANCE_FORCE_STS).
This is an example of the rule setup. The final setup should be done by the Financial Institution.
Rule Attribute
Setup Guidelines
Rule Name
Rule Sub Type (Relation Type)
Description
Attachment
Rule conditions
Rule Action
5.4.2 System Configuration
5.4.2.1 System Parameters
There are no specific System Parameters, which are system parameters, required for the Compliance
Interface.
5.4.2.2 Profiles
There are no specific system profiles required for the Compliance Interface.
Note: For a detailed description of all the profiles, see GPP Online Help.
GPP PAYplus | System Integration - Single Transactions | Page 39
5.4.2.3 Rules
5.4.2.3.1 Interface Selection Rule
Interface selection rules can be configured according to customer’s requirement, in order to select the
relevant Compliance interface.
5.4.2.3.2 Repair and Enrichment Rule
The Repair and Enrichment rule is configured to replace the credit account with the Seized funds
suspense account and to set the MOP as BOOK. The rule bases in its conditions on the Monitor
indicating the instruction for seizing (MU_COMPLIANCE_FORCE_STS).
5.5 Message Data
There are no specific errors and audit trails for this interface.
Possible values of statuses for OFAC Predebit Interface monitor and OFAC Preposting Interface
monitor:
B - Bypassed
N - No Hit
H - Hit
S - Possible Hit
W – Wait (Set when a payment moves to Wait queue)
Z - Seized (Not currently used)
R - Rejected (May be used in case of a Processing/Technical error)
P - Pending (Set when a request is sent)
E - Error (May be used in case of a Processing/Technical error)
6 Feeder Interface
6.1 Overview
This interface can be used by a Feeder system to handoff all types of single payment transactions,
including:
Book transfers: transferring funds between two customers who maintain accounts in the same
financial institution.
Account transfer: transferring funds between a customer/financial institution who has different
accounts in the same financial institution (for example, liquidity sweeps)
Charge billing: debit customer account, credit financial institution PNL account
High value domestic transaction
High value international transaction
Single low value domestic transaction
Outgoing transaction instruction
GPP supports a GPP Standard Feeder format that is suggested to be used for this interface. For
more information on this format, see GPP Technical Guide - Fndt Message Usage for Feeder
Interface – Single Transaction.
GPP can also support a proprietary format as per the financial institution’s preference. It is only
supported, once the initial mapping effort is included between the proprietary format and the GPP
GPP PAYplus | System Integration - Single Transactions | Page 40
attributes, and as long as the necessary information, per the different options, exists in this proprietary
format.
6.2 Processing
6.2.1 Workflow
Parsing and
Capturing transaction
and additional
information provided
Repair
Change details
and Submit
Canceled
Cancel
User
Action
Failed
processing
Wait Rate
HV Flow Processing
FX Handling
Trigger Rate
received and is
favorable over
calculated rate?
No
Use calculated rate
Yes
Wait for better rate
Resent for
FX Handling triggered by
event
WAIT_TRIGGER_RATE
Generate
Acknowledgment
6.2.2 Details
6.2.2.1 Handling the Feeder Request
GPP parses and captures the information from the message. It then submits it to the relevant
processing flow (typically the single high value business flow).
6.2.2.1.1 Parsing
GPP parses the tags and fields of supported message types (for example, pain.001, pain.008 and
MT103).
6.2.2.1.2 Capturing and Storing Persistent Processing Information and Monitors
GPP captures and store the processing persistent information and, if provided, the monitors
information provided by the Feeder system. If using the Standard Fndt message, these are passed
GPP PAYplus | System Integration - Single Transactions | Page 41
within these extensions: ProcessingPersistentInfo and Monitors. If using a financial institution’s
proprietary format that can include such information, it is passed within the relevant fields in this
structure.
Feeder system Transaction reference:
- GPP captures the Feeder system’s transaction reference. If using the Standard Fndt message
it is provided in the P_TX_ID tag (within ProcessingPersistentInfo extension). For more
information on the usage of this attribute see Usage of Transaction Reference.
Suggested or instructed MOP:
- If the transaction is a Credit Transfer, GPP captures the credit MOP. If using the Standard
Fndt message it is provided in the P_CDT_MOP tag within this extension. In addition, GPP
captures the MU_SET_CDT_MOP monitor, if provided, (within Monitors extension) to identify
if the MOP is meant to be a suggested MOP or an instructed MOP. For more information on
the usage of these attributes, see Usage of MOP Information.
- If the transaction is a Collection (Direct Debit), GPP captures the debit MOP. If using the
Standard Fndt message it is provided in the P_DBT_MOP tag within this extension. In
addition, GPP captures the MU_SET_DBT_MOP monitor, if provided, (within Monitors
extension) to identify if the MOP is meant to be a suggested MOP or an instructed MOP. For
more information on the usage of these attributes see Usage of MOP Information.
Debtor and debit account (when provided):
- If the debtor and debit account information is provided for an outgoing credit transfer,
specifically in dedicated fields within the Feeder request (if using the Standard Fndt message
it is passed in the ProcessingPersistentInfo extension), GPP captures this information as the
debtor and debit account information for its processing.
- If the debtor and debit account information is provided in the transaction payload (pain
message), GPP captures it from this source and then derives the full debtor and debit account
according to standard processing.
- For more information on the usage of these attributes see Usage of Account and Customer
Information.
Creditor and credit account (when provided):
- If the creditor and credit account information is provided for an outgoing collection (direct
debit), specifically in dedicated fields within the Feeder request (if using the Standard Fndt
message it is passed in the ProcessingPersistentInfo extension), GPP captures this
information as the creditor and credit account information for its processing.
- If the creditor and credit account information is provided in the transaction payload (pain
message), GPP captures it from this source and then derives the full creditor and credit
account according to standard processing.
- For more information on the usage of these attributes see Usage of Account and Customer
Information.
Reverse Sell Indicator
- GPP captures the Reverse Sell Indicator that is provided in P_RVS_SELL (if using the
Standard Fndt message it is passed in the ProcessingPersistentInfo extension).
- For more information on the usage of this attribute see Usage of Rates Related Information.
6.2.2.1.3 Capturing and Storing Message Fees
When the message fees information is provided within the Feeder request (if using the Standard Fndt
message, within the extension MsgFees), GPP captures it and stores it so that it can be used in the
processing of the message.
GPP first validates that the fee occurrences reported are per existing and valid Fee Types as defined
in GPP. If valid, GPP populates the message fees structure in the PDO, and creates corresponding
records in MSG_FEES table when the message is stored.
GPP PAYplus | System Integration - Single Transactions | Page 42
This table shows the mapping of the different fees attributes to the MSG_FEES entries.
To MSG_FEES Field Name
Taken From
MID
Current message P_MID
APPLY
F_MSG_FEES_FEE_APPLY
MANUAL_FEE
F_MSG_FEES_MANUAL_FEE = ‘CDB’
DEDUCT_FROM
F_MSG_FEES_DEDUCT_FROM
FEE_ACC_AMOUNT
F_MSG_FEES_FEE_ACC_AMOUNT or calculated
FEE_AMOUNT
F_MSG_FEES_FEE_AMOUNT
FEE_AMOUNT_IN_PMT_CCY
F_MSG_FEES_FEE_AMT_IN_PMT_CCY or calculated
FEE_BASE_AMOUNT
F_MSG_FEES_FEE_BASE_AMOUNT or calculated
FEE_CURRENCY
F_MSG_FEES_FEE_CURRENCY
FEE_FORMULA_UID
Set by GPP to ‘CDB’
FEE_PNL_ACCOUNT_CURRENCY
F_MSG_FEES_FEE_PNL_ACC_CUR or retrieved from Fee
type profile
FEE_PNL_ACC_NO
F_MSG_FEES_FEE_PNL_ACC_NO or retrieved from Fee
type profile
FEE_PNL_ACC_OFFICE
F_MSG_FEES_PNL_ACC_OFFICE or retrieved from Fee
type profile
FEE_PNL_AMOUNT
F_MSG_FEES_FEE_PNL_AMOUNT or calculated
FEE_TYPE_UID
F_MSG_FEES_FEE_TYPE_UID
ORIG_FEE_AMOUNT
F_MSG_FEES_ORIG_FEE_AMOUNT or calculated
PAYING_PARTY
F_MSG_FEES_PAYING_PARTY
These fees are handled in the payment processing as CDB fees (fees calculated and received from
an Account Management (CDB) system).
The message fees are associated a Dummy virtual fee formula with the following attributes:
- Name & Description = CBD
- Fee calculation method = Regular
- Fixed fee method = Message
- Percentage = 0
GPP calculates and populates the various amounts (when needed) based on the fee amount;
including:
- Original fee amount
- Fee amount in transaction currency
- Fee amount in base currency
GPP PAYplus | System Integration - Single Transactions | Page 43
- Fee amount in fee account currency
- Fee amount in PNL account currency
6.2.2.1.3.1 Derivation of the P&L Account for Fees
If the Feeder system cannot provide the Fee PNL account, the details of the account should be
maintained on the Fee Type profile. GPP then retrieve these details from the Fee Type profile that
should be provided in Feeder request (if using the Standard Fndt message, within the MsgFees
element (F_MSG_FEES_FEE_TYPE_UID)).
6.2.2.1.3.2 Derivation of the FEE Account
Fee account is derived only if the fees are deducted from the account.
GPP derives the fee account in the following order:
7. If the fee account is provided in the Feeder request within specific tags (if using the Standard Fndt
message, within the ProcessingPersistentInfo extension), GPP uses it as the fee account.
8. If the fee account is provided in the Feeder request within the transaction payload (for example in
pain.001, pain.008 in <chrgsAcct> tag), GPP uses it as the fee account.
9. If the fee account is defined in the relevant Account profile, GPP uses it as the fee account.
10. If the fee account is defined in the relevant Parties profile, GPP uses it as the fee account.
11. If GPP cannot derive the fee account at any point in the process, GPP uses the principle account
as the fee account.
Note: During processing, if there is a fee enrichment rule, it will override all of the above and define
the fee account.
For more information on the usage of fee information see Usage of Fees Information.
6.2.2.1.4 Capturing and Storing Message Rates
When the message rates information is provided within the Feeder request (if using the Standard Fndt
message, within the extension MsgRates), GPP captures it and stores it so that it can be used in the
processing of the message.
GPP populates the message rates structure in the PDO, and creates corresponding records in the
MESSAGERATES table when the message is stored.
This table shows the mapping of the different rates attributes to the MESSAGERATES entries.
To MESSAGERATES Field Name
Taken From
MID
Current message P_MID
CONTRACT
F_FC_CONTRACT
AMOUNT
F_FC_AMOUNT
CCY1
F_FC_CURRENCY1
CCY2
F_FC_CURRENCY2
SPREAD
F_FC_SPREAD
SPREAD_UNITS
F_FC_SPREAD_UNITS
CONVERSION_TYPE
F_FC_CONVERSION_TYPE
GPP PAYplus | System Integration - Single Transactions | Page 44
To MESSAGERATES Field Name
Taken From
FORWARD_CONTRACT
F_FC_FORWARD_CONTRACT
CUSTOMER_ID
F_FC_CUSTOMER_ID
MANUAL_SPREAD
F_FC_MANUAL_SPREAD
LATEST_DATE
F_FC_LATEST_DATE
For more information on the usage of rate information see Usage of Rates Related Information.
6.2.2.1.5 Capturing and Storing Earmark and Balance Information
The balance information, if provided in the Feeder request within specific tags (if using the Standard
Fndt message BICheckInfo extension), as a result of a balance and reservation check in the sending
system, before handoff to GPP. The information may include earmark references and/or balance of
the account. For more information on the usage of these attributes see Usage of Earmark Information.
6.2.2.1.6 Additional Logging
Note that in the case of a Feeder interface the Product configuration on the Interface entry is to not
store the request in the Processing Communications (MESSAGE_EXTERNAL_INTERACTION table),
as this would be a redundant duplicate to the logging of tmessages as it was received, including
additional extensions if provided, in the MINF column of XML_Orig_Msg, that is also visible in the UI
in the Before window on the message screen.
6.2.2.2 Usage of Information Received During Processing
6.2.2.2.1 Usage of Transaction Reference
GPP includes this reference (within P_TX_ID tag) in the acknowledgement/status report sent to
the Feeder system, as a result of advising.
GPP may also need to use a transaction reference to match a cancelation request to an outgoing
transaction.
6.2.2.2.2 Usage of MOP Information
Once reaching the MOP Selection step:
If the transaction is a Credit Transfer, GPP uses the captured Credit MOP in the P_CDT_MOP
during processing.
- When the MU_SET_CDT_MOP monitor is also provided (within Monitors extension) with the
value of F, this MOP is regarded by GPP as an instructed MOP (same as a manually selected
MOP by the user). GPP does not invoke the MOP selection logic, and only performs MOP
Validation on this MOP.
- When this monitor is not provided, or is provided with a different value, the provided MOP (in
P_CDT_MOP) is regarded by GPP as a suggested MOP. The MOP selection rules are
invoked. These rules can be configured to include a condition on the provided P_CDT_MOP,
and hence influence the final MOP selected by these rules.
If the transaction is a Collection (Direct Debit), GPP uses the captured Debit MOP in the
P_DBT_MOP during processing.
- When the MU_SET_DBT_MOP monitor is also provided (within Monitors extension) with the
value of F, this MOP is regarded by GPP as an instructed MOP (same as a manually selected
MOP by the user). GPP does not invoke the MOP selection logic, and only performs MOP
Validation on this MOP.
- When this monitor is not provided, or is provided with a different value, the provided MOP (in
P_DBT_MOP) is regarded by GPP as a suggested MOP. The MOP selection rules are
GPP PAYplus | System Integration - Single Transactions | Page 45
invoked. These rules can be configured to include a condition on the provided P_DBT_MOP,
and hence influence the final MOP selected by these rules.
6.2.2.2.3 Usage of Account and Customer Information
Debtor and debit account (when provided):
- GPP loads additional debtor and debit account information needed for processing from the
relevant Party and Account profiles, if managed in GPP, according to standard processing.
This is done regardless of the source, within the Feeder request (specific tags or the
transaction payload), in which the debtor and debit account information is provided for an
outgoing credit transfer.
Creditor and credit account (when provided):
- GPP loads additional creditor and credit account information needed for processing from the
relevant Party and Account profiles, if managed in GPP, according to standard processing.
This is done regardless of the source, within the Feeder request (specific tags or the
transaction payload), in which the creditor and credit account information is provided for an
outgoing collection (direct debit).
6.2.2.2.4 Usage of Fees Information
Once reaching the Fee Calculation step:
If fees information is provided and is captured within the MSG_FEES table as CDB fees (fees
calculated and received from an Account Management (CDB) system), GPP uses the fees as
provided for the specific Fee Types, (skipping the calculation of fees for these types), and only
adds fees of other Fee Types, if configured and found per the specific transaction.
6.2.2.2.5 Usage of Rates Related Information
Once reaching the FX Rate Calculation step, if relevant:
If rates information is provided and is captured within the MESSAGERATES table, GPP uses the
rate information as provided per the different scenarios specified in Forward Contract, Counter
Rate and Spread, and Trigger Payment.
For all scenarios GPP handles a foreign exchange transaction according to the Reverse Sell
Indicator that is provided and captured in P_RVS_SELL.
- When the Reverse Sell Indicator is set to 1, GPP handles it as a Reverse Sell (fixed debit
amount).
- When the Reverse Sell Indicator is not set to 1 or is not present, GPP handles it as standard
(fixed credit amount).
6.2.2.2.5.1 Forward Contract
In a scenario when MsgRates element is received with F_FC_FORWARD_CONTRACT_TYPE
set to 0, GPP treats the rate received in the F_FC_RATE tag as the final rate that is applied to the
transaction, unless the rate expiration is quoted in F_FC_LATEST_RATE tag and is earlier than
the current business date. When this rate is valid, the GPP rates and spreads are not used.
If the F_FC_LATEST_DATE tag quotes an earlier date than the current business date, the
transaction is sent to the FX Rate Repair queue.
Note: if no F_FC_LATEST_DATE is provided, the transaction continues processing, and the
contract never expires.
F_FC_SPREAD and F_FC_SPREAD_UNITS may be included in the MsgRates element for
informational display. Even if they are included, they will not be used in the currency calculation
when the F_FC_FORWARD_CONTRACT = 0.
Note: Rate Usage profile can be the same one used for non-contract transactions s, as the
contract data overrides any other settings.
GPP PAYplus | System Integration - Single Transactions | Page 46
If transaction is stopped, for example in Repair or NSF, or any other manual or wait queue, GPP
goes back through the FX conversion process, and uses the contract rate again. The
F_FC_LATEST_DATE is also rechecked against the current business date at that point.
6.2.2.2.5.2 Counter Rate and Spread
In a scenario when MsgRates element was received with F_FC_FORWARD_CONTRACT_TYPE
set to 3, the rate received is regarded as an immediate rate that can be used if the transaction is
processed STP (straight-through).
If the transaction stops in REPAIR, NSF or any other manual or wait queues, the GPP rates are
used instead of this rate, and GPP uses the F_FC_SPREAD and FC_SPREAD_UNITS in the
contract to calculate a final rate.
Note: This type of contract provides a customer with a rate, if used immediately, and protects the
customer if the transaction stopped, with a good spread that is applied on the rate that is relevant
when the transaction is released for processing.
6.2.2.2.5.3 Trigger Payment
In another scenario in which MsgRates element is received with
F_FC_FORWARD_CONTRACT_TYPE set to 3, and a rate is included in the
F_FC_TARGET_RATE tag (instead of the F_FC_RATE tag).
GPP calculates the rate, based on GPP rates, using the contract spread received within the
MsgRates element (F_FC_SPREAD and FC_SPREAD_UNITS).
GPP then compares the calculated rate to the Target rate, but only if Latest Date is not earlier
than current business date.
- If the GPP calculated rate is favorable or equal to the Target rate, this rate is used to execute
the transaction.
- If the calculated rate is higher (more expensive for the customer) than the Target rate, the
transaction is routed to Wait FX queue (P_FC_INFO_IND is set to T).
- From this queue a retry mechanism (based on an event WAIT_TRIGGER_RATE) invokes a
re-calculation of the rates per this transaction, and again the comparison to the Target rate is
performed.
- If the Latest date is reached without achieving the Target rate, GPP calculated rates with the
contract spread and this rate is used to execute the transaction.
6.2.2.2.6 Usage of Earmark Information
The earmark reference information, if provided, is used when creating posting entries for this
message, and it is quoted in the posting entries sent out in the Posting Request.
This field, if not empty, can also be used in the BI Bypass rule, if it is not necessary to do an additional
Balance Check (additional to the one performed in the sending system prior to handoff to GPP). If the
Balance Inquiry is not skipped, when such a reference already is quoted, the reference needs to be
sent within the Balance Inquiry request, to allow matching and releasing of the old reference in the
financial institution’s system.
6.2.2.3 Response/Acknowledgment Initiation
The GPP advising mechanism is responsible for providing a response message on transaction
initiation, as well as for providing advises on the progress of the transaction (including crediting and
debiting the customer account). One of the supported options within this mechanism is to provide the
sending system the structure of the Fndt message as an advice. In this case GPP includes the
Feeder system reference number (P_TX_ID), if received within the Feeder Request in the Fndt
message (Feeder response) advice.
The Advice initiation can be configured to be invoked when transaction reaches various statuses
(Advising Type Selection rules are invoked every time the process stops, meaning that whenever the
transaction is stopped on a manual, waiting or final status).
GPP PAYplus | System Integration - Single Transactions | Page 47
See details on recommended configuration in Advising Type Selection (172).
6.3 Manual Handling
This section describes the various scenarios in which a single transaction may be stopped after being
handed off via a Feeder request:
In a wait queue until the relevant response is received, or
A manual queue due to information received from an interface
The description is per such specific manual queues. For a summary of actions per queue, see
Appendix A: Manual Actions per Queues.
6.3.1 Wait Queues
6.3.1.1 Wait Rate (WAITRATE) Queue
A single transaction is stopped in this queue whenever it is waiting for an up-to-date rate. In relation
with the Feeder interface, this can occur when the Feeder request provided a Target Rate, and the
computed GPP rate was not favorable to this Target Rate. In this case, the transaction is routed to
this queue to wait for an automated release and retry via the WAIT_TRIGGER_RATE event.
6.3.2 Manual Handling Queues
6.3.2.1 Repair Queue
A single transaction may be stopped in this queue, due to functional or technical failures, when
handling the Feeder request or the transaction itself.
In this queue the following actions can be performed:
Make amendments to the transaction details and Submit it for re-processing.
Cancel: Instructs GPP to cancel the message.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, or
reverse posting, when required, depending when in the flow it is routed to Repair.
6.4 Business Setup and System Configuration
6.4.1 Business Setup
6.4.1.1 System Parameters
There are no specific System Parameters, which are business parameters, required for the Feeder
Interface.
6.4.1.2 Profiles
There are no specific GPP profiles required for the Feeder Interface.
Note: For a detailed description of all the profiles, see GPP Online Help.
6.4.1.3 Business Rules
6.4.1.3.1 Advising Type Selection (172)
The Advising Type Selection rules should be configured for the scenarios in which a notification is
required to be created and sent back to the Feeder system as a response.
These rules are invoked whenever the transaction is stopped in a manual, waiting or final queue.
The recommended configuration is the following, but any financial institution can decide to configure
less or more that these notifications.
GPP PAYplus | System Integration - Single Transactions | Page 48
A recommended set of notification can be provided when transaction reaches the following statuses:
A success advise with ACTC in the <TxSts> of the created pain.002 – when transaction reaches
COMPLETE, WAIT_ACK or WAIT_CONFIRMATION
Note: rules can restrict a double success invocation in case of State=COMPLETE and Previous
Status is either of WAIT_ACK or WAIT_CONFIRMATION, in which case a success notification
was already sent for an outgoing transaction.
An advise informing on a Pending state with PNDG in the <TxSts> of the created pain.002 – on
the first time the transaction is written into the GPP DB (Previous Status is RECEIVED) and
transaction reaches the different wait and manual queues - WAITCOMPLIANCECHECK,
CDBWAIT, BIWAITQ, POSTREST, NSF, POSTEX or REPAIR.
A failure advise with RJCT in the <TxSts> of the created pain.002, when transaction reaches
CANCELLED, RETRUNED, REJECTED or NAK.
6.4.1.4 Permissions
Permissions need to be granted to users that need to configure the rules related to the Feeder
interface.
6.4.2 System Configuration
6.4.2.1 System Parameters
There are no specific System Parameters, which are business parameters, required for the Feeder
Interface.
6.4.2.2 Profiles
These are the details of the required setup in GPP system profiles for the Feeder Interface.
Note: For a detailed description of all the profiles, see GPP Online Help.
6.4.2.2.1 Interfaces
Relevant Interfaces entries should be configured for the Feeder interface request and for the
Acknowledgment (ACK) notification that serves as a response.
As the Feeder request is an Incoming interface, there is no relevancy for Inactive behavior
configuration, as when interface is down nothing will be received from it.
For a description of the relevant fields, see the GPP Online Help or the GPP Interfaces Technical
Guide.
Note: When the Fndt Message format is defined as the structure to use for a specific interface type
(Standard), GPP can also be setup to control which sections of the generic Fndt Message structure
are to be sent out for this Request/Response, from a maximum with a full structure (including all the
message related attributes), to a minimum specific per interface type. For example, for Feeder
interface only the sections quoting the transaction text and a few ProcessingPersistentInfo attributes.
6.4.2.2.2 Event Management
The event WAIT_TRIGGER_RATE should be set to release up to 10 transactions from the Wait Rate
(WAITRATE) queue every 5 minutes.
Note: There is another WAITRATE event that is triggered when a user updates the exchange rate
profile.
Event Name
Event Description
Mode
Minutes
Batch Size
WAIT_TRIGGER_RATE
Retry transactions with FX trigger
rate
0
5
10
GPP PAYplus | System Integration - Single Transactions | Page 49
6.4.2.3 Rules
6.4.2.3.1 Interface Selection
Interface Selection rules, selecting the relevant Interfaces entries, should be configured for the Feeder
interface request and for the Acknowledgment (ACK) notification that serves as a response.
6.5 Message Data
There are no specific Message Attributes, errors and audit trails for this interface.
7 Online Foreign Exchange Interface
7.1 Overview
GPP uses a Currency Conversion mechanism to handle the conversion between two currencies,
either by using a quoted rate between them or by using a cross currency to obtain a conversion rate.
The exchange rate can be obtained from inside GPP or from an external system.
This section provides details when the exchange rate is obtained from an external system.
For a detailed description of the GPP processing for Currency conversions, see GPP Business Guide
Currency Conversion.
GPP PAYplus | System Integration - Single Transactions | Page 50
7.2 Processing
7.2.1 Workflow
FX Payment
SWIFT/Clearing/
CREATE GPP Accounting
System
External FX
System
Payment
Processing
Customer
Contracts, Rates
Customer Data
Account and Customer Info
Contract
received?
Continue
Processing
(using
Indicative Rate)
Request: VALLOCK/RSSTP
Account Lookup
No
Response: Positive/Negative
FX REPAIR
Customer
Contracts, Rates
Request: VALLOCK
Response Type VALLOCK/2nd ACCLOCK: Positive/Negative
Negative
FXWAITQ
Positive
Continue
Processing
User Action
SCHEDULED
queue
No
FX Tab Options
Get Deals
Get Rate
Accept/Reject Quote
Lock Deal (Submit)
FX Positive Responses
Contract validated
Rate auto-booked
under threshold for
Non-Dealing and pre-
defined Dealing
customers
Submit
FX Responses
VALLOCK upon
Submit for
contract
2nd ACCLOCK
upon Accept for
rate
Processing
Date?
Yes
Yes
Above Threshold?
FXWAITQ
Response Type
Negative
Positive
Initial Requests: GETDEALS/GETRATE
Initial Responses: Deals/Quote
Secondary Request: ACCLOCK/REJRATE
Accept/Reject
Rate
REJRATE: Positive/Negative
No
Yes
1st ACCLOCK
Response
Type
Positive
Negative
Payment
GPP PAYplus | System Integration - Single Transactions | Page 51
7.2.2 Details
7.2.2.1 Transaction Received in GPP
An external foreign exchange (FX) interface call is triggered in GPP after debit/credit side derivation,
MOP and fees, and before posting.
1. GPP evaluates the Rate usage selection rules, applying the relevant Rate usage profile. The Rate
Usage profile is configured with the external interface name
2. GPP applies an indicative rate as the standard rate, which is later overridden by the external
received rate.
3. On processing GPP initiates a request to the external FX engine:
- If a contract is included in the transaction and regardless if the transaction exceeds a defined
threshold, GPP generates a Validate and Lock (VALLOCK) request, and routes the
transaction to FX Wait queue.
- If no contract is included in the transaction and the transaction amount is below a defined
threshold, GPP generates a Rate Request STP (RRSTP) request, and routes the transaction
to FX Wait queue.
- If no contract is included in the transaction and the transaction amount exceeds a defined
threshold, the transaction is routed to a manual queue as configured in the Rate usage
profile’s field Above threshold to go (for example, FX Rate Repair queue, Repair queue).
4. When GPP receives and matches a response from the FX interface:
- Positive response for a validated contact: The transaction continues to be processed.
- Negative (error) response: The transaction is routed to FX Rate Repair queue for user
intervention.
5. If the response is not received within a configurable timeout period, timeout will be retried per
configured number of retries on the Interface Type, after which - Interface becomes inactive and
Online FX request is treated as failed. For more details on Interface Timeout behavior, see GPP
Technical Guide - Interfaces document
7.2.2.2 Manually Handled Transaction with Online FX Conversion
A transaction that requires FX conversion can be created/repaired manually. On the transaction’s FX
tab in the GPP User Interface, the user can either:
Specify a single customer contract ID and its respective rate. Upon Submit, a Validate and Lock
(VALLOCK) request is sent to the FX engine.
Leave the FX tab empty. Upon Submit, a Rate Request STP (RRSTP) request is sent to the FX
engine.
Based on the response received from the FX engine, the transaction continues with the process or is
routed to FX repair queue (see step 4 in Transaction Received in GPP).
7.2.2.3 Transaction with Debit and Credit Online FX Conversion
GPP does not support conversion on both debit and credit side.
When a transaction requires both Debit and Credit currency conversion, the transaction is routed to a
manual queue for user intervention, for example FX Repair.
7.3 Manual Handling
This section describes the various scenarios in which a single transaction may be stopped in relation
with the Online FX interface.
GPP PAYplus | System Integration - Single Transactions | Page 52
7.3.1 Wait Queues
7.3.1.1 FX Wait Queue
A single transaction is stopped in this queue when it is waiting for a response from the external FX
engine.
In this queue the following actions can be performed:
Send to FX Repair: Instructs GPP to send the transaction to the FX Repair (FXREPAIR) queue
for manual adjustments.
GPP Processing:
- The transaction is routed to the FX Repair (FXREPAIR) queue.
Processing Communications: Opens the Processing Communications page to allow instructing to
resend the interface request.
GPP Processing:
- The Processing Communications page is opened for user to resend the interface request,
quoting the same event ID (if exists).
Cancel: Instructs GPP to cancel the transaction. This is relevant for outgoing transactions only.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, and
reverse posting, when required.
7.3.2 Manual Handling Queues
7.3.2.1 FX Rate Repair Queue
A transaction is routed to the FX Repair queue, in order to repair the FX information, so that it can
continue to be processed.
In this queue the following actions can be performed:
Submit: Make amendments to the details, and Submit it for re-processing.
To add a Contract ID:
- Input Contract ID in FX tab.
- Submit the payment.
- GPP generates a Validate and Lock (VALLOCK) request and routes the payment to FX Wait
Queue (same as when the contract is included in original payment)
Get Deals: Define the relevant contract and Submit it for re-processing.
- GPP sends a GETDEAL request (synchronic) to the external FX engine.
- A positive response from the FX engine returns all valid contracts for the relevant currency
pair and amount.
Note: A negative response displays the relevant error transaction.
- GPP stores the contract information (contract reference, amount) and displays it on the
transaction’s FX tab (MessageRates table).
- A single contract needs to be displayed on the FX tab. All irrelevant contracts need to be
deleted by selecting the contract, clicking Delete, and then Recalculate to save the changes
made to the grid.
- Click Submit, the Validate and Lock (VALLOCK) request is sent to the external FX engine.
- GPP routes the transaction to FX Wait Queue.
GPP PAYplus | System Integration - Single Transactions | Page 53
Note: If required, all the contracts can be deleted from the FX tab, and a dealer rate can be
requested from the FX engine by clicking Get Rate.
Get Rate: Request a dealer rate for the relevant currency and pair amount.
GPP Processing
- GPP generates a GETRATE request (synchronic), and routes the transaction to FX Wait
Queue.
- In the response from the external FX engine, a respective Dealer Rate is auto-populated on
the FX tab and a dialogue box appears displaying the rate and a countdown timer. The user
has two options:
Approve: Accepts the quote, sends an Accept and Lock (ACCLOCK) request, and routes
the transaction to FX Wait queue to wait for a response from the external FX engine.
Note: If a positive response is received, GPP continues to process the transaction. If a
negative response is received, the transaction is routed back to FX Repair queue.
Reject: Rejects the quote, closes the dialogue box, sends a Reject Rate (REJRATE)
response and clears the received rate from the FX tab table, allowing the user to continue
to process the transaction.
Note: If a negative response is received, a relevant error message is generated.
Note: If the quote expires (the countdown timer on the dialogue box reaches 0 seconds), the
quote expires and both Approve and Reject buttons are disabled.
Cancel: Instructs GPP to cancel the transaction.
GPP Processing:
- The transaction is routed to cancellation flow, including earmark release, when required, or
reverse posting, when required.
7.4 Business Setup and System Configuration
7.4.1 Business Setup
7.4.1.1 System Parameters
These System Parameters are business parameters, which are related to the FX functionality.
Name
Description
FX_THRESHOLD_AFTE
R_SCHEDULE
Determines if the FX threshold defined in a Rate Usage profile is
checked on the actual processing date of the transaction (after
schedule).
Y - FX threshold is checked by GPP on the transaction 's processing
date
N - FX threshold is checked by GPP when the Rate Usage profile
associated with the transaction is evaluated
7.4.1.2 Profiles
These are the details of the required setup in GPP system profiles for the FX Interface.
Note: For a detailed description of all the profiles, see GPP Online Help.
7.4.1.2.1 Rate Usage
For an external FX call, the Rate Usage profile should be defined with a Standard rate sheet and the
relevant interface name under Rate interface name fields.
In addition, the Threshold for direct conversion may be defined, along with the relevant manual queue
under Above threshold go to field.
GPP PAYplus | System Integration - Single Transactions | Page 54
Example:
Profile name: HV_EFX
Profile description: External FX Rate Usage
Rate type: STANDARD
Rate interface name: EFX_OUT_ASYNC
Above threshold goes to: FX Rate Repair
7.4.1.3 Rules
Rate Usage for Credit Side Conversion, Rate Usage for Debit Side Conversion and Rate Usage for
Base Conversion should be setup to select the external FX Rate usage.
The rules should be set up based on the Financial Institution’s business requirements.
7.4.2 System Configuration
7.4.2.1 System Parameters
There are no specific System Parameters, which are system parameters, required for the FX
Interface.
7.4.2.2 Profiles
There are no specific GPP system profiles required for the FX Interface.
Note: For a detailed description of all the profiles, see GPP Online Help.
7.4.2.3 Rules
7.4.2.3.1 Interface Selection Rule
Interface selection rules can be configured according to the Financial Institution’s requirements, in
order to select the relevant Online FX interface, specifically when multiple interfaces are used.
A-Sync interface is selected based on the Rate usage profile setup.
Sync interface is selected based on user’s manual action (Get rate or Get deals).
This is an example of the rule setup. The final setup should be done by the Financial Institution.
Rule Attribute
Setup Guidelines
Rule Name
HV_EFX_SYNC
Rule Sub Type (Relation Type)
0
Description
Interface selection for Sync FX interface
Attachment
***
Rule conditions
[Button ID] In Get Deals, Get Rate
Rule Action
EFX_OUT_SYNC
7.5 Message Data
There are no specific Message Attributes, errors and audit trails for this interface.
GPP PAYplus | System Integration - Single Transactions | Page 55
8 Posting Interface
For information on the business functionality and business setup for the posting logic and interface,
see the GPP Posting Business Guide.
GPP PAYplus | System Integration - Single Transactions | Page 56
Appendix A: Manual Actions per Queues
Only the manual actions which have a GPP process for the Interfaces are described in this appendix.
For all other actions, see GPP Online help.
A single transaction may be stopped in relation to interfaces in these queue types.
Note: The actions are always available (subject to specific user permissions) unless stated otherwise
in the Description column.
Interface
Type
Queue
Action
Description
Account
Lookup
Wait CDB
Response
Cancel
Initiates the cancelation of the transaction.
The transaction is routed to cancellation flow,
including earmark release, when required (for
example, if the Account Lookup is pending on the
target credit account, while Balance Inquiry on
the debit account already took place), or reverse
posting, when required (for example, if the
Account Lookup is on the target credit account,
while Posting on the debit leg already took place).
Balance
Inquiry
Wait Balance
Inq.
Response
Force
GPP continues processing even though the no
response was received.
Note: Only entitled users whose user profile
maximum force limit amount is greater than the
message amount can use this action.
Balance
Inquiry
Wait Balance
Inq.
Response
Retry Bal. Inq.
GPP retries the processing of the message.
The CDB monitor is kept as P, if external Account
Lookup is required and was performed earlier in
the flow, to allow skipping an additional
invocation of the Account lookup, when message
is reprocessed.
When reaching the points in the flow for. another
request - Balance inquiry, and as the Balance
Inquiry monitor is not set to P, as an indication
that this step already ended successfully, GPP
generates a new request to the HOST system,
quoting a new Event ID. The transaction is routed
to Wait Balance Inq. (BIWAITQ) pending
response from HOST system.
Balance
Inquiry
Wait Balance
Inq.
Response
Send to Repair
GPP sends the message to the Repair queue for
manual adjustments
Balance
Inquiry
Wait Balance
Inq.
Response
Cancel
Initiates the cancelation of the transaction.
The transaction is routed to cancellation flow,
including earmark release, when required, and
reverse posting, when required (for example, if
the Balance Inquiry is pending on the second leg
(target debit account), and Posting was already
performed on first leg).
Feeder
Wait Rate
It is an event and
not an action
The automated WAIT_TRIGGER_RATE event
releases the transaction for re-computation of the
GPP PAYplus | System Integration - Single Transactions | Page 57
Interface
Type
Queue
Action
Description
rate for it, in a scenario in which it is stopped in
this queue, waiting for an up-to-date rate. Such a
scenario may be, a scenario in which Feeder
Interface provided a Target Rate, and the
computed GPP rate was not favorable to this
Target Rate.
Posting
Wait Posting
Release – As
Positive Posting
If configured for dual approval, the transaction
is routed to the Approve Manual Posting
Response queue for approval/rejection.
If not configured for dual approval, (or after
approval within the above queue), GPP
releases the transaction to continue
processing, even though a Posting request
was previously sent for it, and no response
received, emulating a positive Posting
response.
Posting
Wait Posting
Release – As
Negative Posting
If configured for dual approval, the transaction
is routed to the Approve Manual Posting
Response queue for approval/rejection.
If not configured for dual approval, (or after
approval within the Approve Manual Posting
Response queue), GPP releases the
transaction to continue processing, even
though a Posting request was previously sent
for it, and no response received, emulating a
negative Posting response.
Posting
Wait Posting
Cancel
Initiates the cancelation of the transaction.
The transaction is routed to cancellation flow,
including earmark release, when required, and
reverse posting, when required (for example, if
Posting is pending on the second leg, and
Posting was already performed on first leg).
Account
Lookup
Inactive CDB
Cancel
Initiates the cancelation of the transaction.
The transaction is routed to cancellation flow,
including earmark release, when required (for
example, if the Account Lookup cannot be
performed on the target credit account, while
Balance Inquiry on the debit account already took
place), or reverse posting, when required (for
example, if the Account Lookup cannot be
performed on the target credit account, while
Posting on the debit leg already took place).
Balance
Inquiry
Inactive BI
Cancel
Initiates the cancelation of the transaction. The
transaction is routed to cancellation flow,
including earmark release, when required, and
reverse posting, when required (for example, if
the Balance Inquiry cannot be performed on the
second leg (target debit account), and Posting
was already performed on first leg).
Posting
Stop Posting
Cancel
Initiates the cancelation of the transaction.
GPP PAYplus | System Integration - Single Transactions | Page 58
Interface
Type
Queue
Action
Description
The transaction is routed to cancellation flow,
including earmark release, when required, and
reverse posting, when required (if Posting cannot
be performed on the second leg, and Posting was
already performed on first leg).
Feeder /
Account
Lookup /
Balance
Inquiry /
Posting
Repair
Submit
Submits the transaction for reprocessing after
user amendments to the transaction details.
When reaching the point/s of Account Lookup
- If the relevant CDB monitor is not set to P,
to indicate a successful Account Lookup,
or if the relevant account was updated by
the user, an additional invocation of the
Account lookup for the relevant account is
triggered.
When reaching the point of Balance Check
- If the BI monitor is not set to P (either it
was stopped before or due to a Balance
Inquiry response), the Balance Inquiry
interface is triggered.
- If this monitor is P, to indicate a successful
Balance Inquiry, but the Posting monitor
indicates failure, and if relevant transaction
attributes were changed (account, amount,
value date), and if working in Earmark
mode, an Earmark Release request along
with the new Balance Inquiry with earmark
hold request are triggered, each quoting a
new event ID.
When reaching the point of Posting the
Posting interface is triggered.
- The Posting entries are re-calculated and
compared with previous entries not already
marked as successful/reversed. I they are
different (may happen when relevant
transaction attributes (account, amount,
value date) were changed), reversed
posting entries are created for these non-
final entries, along with the newly
calculated entries. These are included in
the Posting request/s and are sent, quoting
a new Event ID.
Note: The Account Lookup on the credit account
is performed on the account of the party that is
first in the credit chain (after the GPP chain
enrichment). If the Credit account was entered
manually, while in the Repair queue, and needs
to be validated via Account Lookup, it must quote
the same first in chain account, as GPP does not
take it into account for the credit Account Lookup.
Feeder /
Account
Lookup /
Balance
Repair
Cancel
Initiates the cancelation of the transaction.
GPP PAYplus | System Integration - Single Transactions | Page 59
Interface
Type
Queue
Action
Description
Inquiry /
Posting
The transaction is routed to cancellation flow,
including earmark release, when required, or
reverse posting, when required.
Balance
Inquiry /
Posting
Insufficient
Funds
Force Ins. Funds
GPP continues processing even though the debit
account has insufficient funds.
If routed to this queue due to Balance Inquiry
response (the BI interface monitor is not P),
the Balance inquiry interface generates a new
request to the HOST system, quoting a new
Event ID, and indicating that the user allows
transaction processing to continue even
though the account has insufficient funds (if
using the Standard Fndt Message -
MU_NSF_FORCE_STS = 1 within the added
Monitors extension). In Balance Inquiry with
Earmark mode, the transaction is routed to
Wait Balance Inq. Response (BIWAITQ)
pending response from HOST system.
If routed to this queue due to Posting
response (the relevant Posting interface
monitor is not P), Posting interface is triggered
to generate new request/s to the HOST
system, quoting a new event ID and including
the additional information of the user decision
to force the processing even with no sufficient
funds in the account, either specifically
quoting the MU_NSF_FORCE_STS monitor
as 1, or providing a more general force
indication, for all posting entries, which is
relevant for both user actions of posting
restriction override and force NSF (if using the
Standard Fndt Message -
F_POSTING_INFO_FORCE_POST_IND=1).
The transaction is routed to Wait Posting
(MP_WAIT) pending response from HOST
system.
Note: Only entitled users whose user profile
maximum force limit amount is greater than the
message amount can use this action button.
Balance
Inquiry /
Posting
Insufficient
Funds
Retry Ins. Funds
GPP performs the Balance Inquiry or posting
interface call again.
Transaction is submitted back to try reprocessing
again, eventually triggering another invocation of
Balance Inquiry or Posting (depending on the
interface which failed for Insufficient Funds).
Interface generates new request/s to the HOST
system, quoting a new event ID. The transaction
is routed to Wait Balance Inq queue or Wait
Posting queue (depending on the interface type),
pending response from HOST system.
GPP PAYplus | System Integration - Single Transactions | Page 60
Interface
Type
Queue
Action
Description
Balance
Inquiry /
Posting
Insufficient
Funds
Send to Repair
GPP sends the transaction to the Repair queue
for manual adjustments.
Balance
Inquiry /
Posting
Insufficient
Funds
Cancel
Initiates the cancelation of the transaction.
The transaction is routed to cancellation flow,
including earmark release, when required, or
reverse posting, when required.
Account
Lookup /
Balance
Inquiry /
Posting
Posting
Restrictions
Override
GPP overrides the restriction
MU_STOP_FLAGS_OVERRIDE_STS is set
to O, to indicate that the posting restriction
was overridden, and processing continues
from this point in the flow.
For Account Lookup, if the relevant CDB
monitor is not already P (if the failure with
posting restrictions returned in an Account
Lookup response), it is set to P to allow
skipping an additional invocation of the
Account Lookup on this account, when
message is reprocessed.
For Balance Inquiry, when reaching the point
of Balance Check, whether the first time or as
part of the re-processing, but only if the BI
monitor is not P (meaning that the transaction
was routed to this queue later in the flow due
to a Posting response), the Balance inquiry
interface generates a request to the HOST
system, quoting a new event ID and indicating
that the restriction was overridden (if using the
Standard Fndt Message -
MU_STOP_FLAGS_OVERRIDE_STS = O). In
Balance Inquiry with Earmark mode, the
transaction is routed to Wait Balance Inq.
Response (BIWAITQ) pending response from
HOST system.
When reaching the point of Posting, whether
the first time or as part of the re-processing,
Posting interface generates a request to the
HOST system, quoting a new Event ID and
including the additional information of the user
decision to override posting restrictions, either
specifically quoting the
MU_STOP_FLAGS_OVERRIDE_STS monitor
as O, or providing a more general force
indication, for all posting entries, which is
relevant for both user actions of posting
restriction override and force NSF (if using the
Standard Fndt Message -
F_POSTING_INFO_FORCE_POST_IND=1).
.indicating per each posting entry that it should
be forced if using the Standard Fndt Message
- F_POSTING_INFO_FORCE_POST_IND=1)
due to user decision – either force from
Insufficient Funds (NSF) or restrictions
GPP PAYplus | System Integration - Single Transactions | Page 61
Interface
Type
Queue
Action
Description
overridden from Posting Restrictions
(POSTREST). If required, but not in the
minimal request scope, the Posting request
can include, within the added Monitors
extension, the specific monitor, to indicate
which of these was selected, (for forcing
insufficient funds -MU_NSF_FORCE_STS = 1
or for overriding restrictions
MU_STOP_FLAGS_OVERRIDE_STS = O).
The transaction is routed to Wait Posting
(MP_WAIT) pending response from HOST
system.
Note: This button is only available to allow a user
to override the restriction, when the transaction
was stopped due to an overridable Stop Flag.
Account
Lookup /
Balance
Inquiry /
Posting
Posting
Restrictions
Retry Post. Rest
GPP tries to process the transaction again.
If routed to this queue due to Account Lookup
response, another attempt of the Account
lookup (for the relevant side which failed
previously due to posting restrictions) is
performed. So, in this case, the relevant CDB
monitor is cleared to simulate an initial
invocation of Account Lookup. The transaction
is routed to Wait CDB Response (CDBWAIT)
pending response from HOST system.
If routed to this queue due to Balance Inquiry
or Posting response, the relevant CDB
monitor is kept as P, if external Account
Lookup is required and was performed earlier
in the flow, to allow skipping an additional
invocation of the Account lookup, when
message is reprocessed. When reaching the
points in the flow of Balance inquiry or
Posting, and only when the relevant monitor is
not P, the relevant Interface generates new
request/s to the HOST system (Posting
interface uses same posting entries), quoting
a new Event ID. The transaction is routed to
Wait Balance Inq. (BIWAITQ) or Wait Posting
(MP_WAIT), depending on the interface type,
pending response from HOST system.
Account
Lookup /
Balance
Inquiry /
Posting
Posting
Restrictions
Send to Repair
Sends the message to the Repair queue for
manual adjustments.
Account
Lookup /
Balance
Inquiry /
Posting
Posting
Restrictions
Cancel
Initiates the cancelation of the transaction.
The transaction is routed to cancellation flow,
including earmark release, when required, or
reverse posting, when required.
GPP PAYplus | System Integration - Single Transactions | Page 62
Interface
Type
Queue
Action
Description
Posting
Posting
Exception
Queue
Release – As
Positive Posting
If configured for dual approval, the transaction
is routed to the Approve Manual Posting
Response for approval/rejection.
If not configured for dual approval (or after
approval within the Approve Manual Posting
Response queue), releases the transaction to
continue processing, even though a negative
posting response was received (probably after
manually handling in the financial institution’s
accounting system), emulating an overriding
positive Posting response.
Posting
Posting
Exception
Queue
Send to Repair
Sends the message to the Repair queue for
manual adjustments.
Posting
Posting
Exception
Queue
Cancel
Initiates the cancelation of the transaction,
including earmark release, when required. If
partial posting has been successfully performed,
the successful posting entries are reversed.
Compliance
Wait OFAC
Queue
Processing
Communications
Opens the Processing Communications page for
a user to resend the interface request, quoting
the same event ID (if exists).
Compliance
Wait OFAC
Queue
Force
Instructs GPP to continue processing the
message as if no hit was detected.
Compliance
Wait OFAC
Queue
Reject/Return
Opens a new Transaction page for users to input
required data and submit.
The outgoing return is processed to completion to
be sent out.
When return is in Complete, original transaction
is routed to Returned queue.
Compliance
Wait OFAC
Queue
Send to Repair
Instructs GPP to send the message to the Repair
(REPAIR) queue for manual adjustments.
Compliance
Wait OFAC
Queue
Cancel
Initiates the cancelation of the outgoing
transaction, including earmark release and
reverse posting, when required.
Compliance
OFAC
Possible Hit
Queue
Force
Instructs GPP to continue processing the
message as if no hit was detected.
Compliance
OFAC
Possible Hit
Queue
Cancel
Initiates the cancelation of the outgoing
transaction, including earmark release and
reverse posting, when required.
Compliance
OFAC Hit
Queue
Send to Repair
Instructs GPP to send the message to the Repair
(REPAIR) queue for manual adjustments.
Compliance
Repair
Submit
Submits the transaction for reprocessing after
user amendments to the transaction details, for
GPP PAYplus | System Integration - Single Transactions | Page 63
Interface
Type
Queue
Action
Description
example replace the Credit Account with a
Suspense Account.
Compliance
Repair
Cancel
Initiates the cancelation of the outgoing
transaction, including earmark release and
reverse posting, when required.
Online FX
FX Wait
Queue
Send to FX Repair
Routes the message to the FX Repair
(FXREPAIR) queue for manual adjustments.
Online FX
FX Wait
Queue
Processing
Communications
Opens the Processing Communications page for
a user to resend the interface request, quoting
the same event ID (if exists).
Online FX
FX Wait
Queue
Cancel
Initiates the cancelation of the transaction,
including earmark release and reverse posting,
when required.
Online FX
FX Rate
Repair
Queue
Submit
Submits the transaction for reprocessing after
user amendments to the transaction details (for
example, add Contract ID).
GPP generates a Validate and Lock (VALLOCK)
request and routes the transaction to FX Wait
Queue (same as when the contract is included in
original transaction)
Online FX
FX Rate
Repair
Queue
Get Deals
Sends a GETDEAL request (synchronic) to the
external FX engine, and routes the transaction to
FX Wait Queue
A positive response from the FX engine
returns all valid contracts for the relevant
currency pair and amount.
Note: For a negative response the relevant
error message are displayed
GPP stores the contract information (contract
reference, amount) and displays it on the
transaction’s FX tab (Message Rates table).
The FX tab should only display a single
contract. All irrelevant contracts need to be
deleted.
If required, all the contracts can be deleted from
the FX tab, and a dealer rate can be requested
from the FX engine by clicking Get Rate
Online FX
FX Rate
Repair
Queue
Get Rate
Sends a GETRATE request (a dealer rate for the
relevant currency and pair amount) to the
external FX engine, and routes the transaction to
FX Wait Queue.
In the response from the external FX engine, a
respective Dealer Rate is auto-populated on the
FX tab and a dialogue box appears displaying the
rate and a countdown timer. The user has two
options:
Approve: Accepts the quote, sends an Accept
and Lock (ACCLOCK) request, and routes the
GPP PAYplus | System Integration - Single Transactions | Page 64
Interface
Type
Queue
Action
Description
transaction to FX Wait queue to wait for a
response from the external FX engine.
Note: The FX Engine sends two separate
responses. For the transaction to continue
processing the two responses must be
positive, otherwise the transaction is routed
back to FX Repair queue.
Reject: Rejects the quote, closes the dialogue
box, sends a Reject Rate (REJRATE)
response and clears the received rate from
the FX tab table, allowing the user to continue
to process the transaction.
Note: If a negative response is received, a
relevant error message is generated.
Note: If the quote expires (the countdown timer
on the dialogue box reaches 0 seconds), both
Approve and Reject buttons are disabled.
Online FX
FX Rate
Repair
Queue
Cancel
Initiates the cancelation of the transaction,
including earmark release and reverse posting,
when required.
Appendix B: Glossary
Term
Description
CDB
Customer Database
An external database hosted and maintained by the financial institution.
Feeder
A customer-facing (front-end) system that enables GPP to input or capture
transactions and transaction-related messages.
Fndt Message
FuNDs Transfer Message
A GPP proprietary message in XML format that includes the full set of
information as received, enriched, computed, or manually updated for
transaction or transaction-related message. Messages in this structure can be
used to interact with financial institution systems and other supporting interfaces.
GPP
Global PAYplus
Finastra’s state-of-the-art global payment services hub.
ISO
International Organization for Standards
An international standard-setting body composed of representatives from various
national standards organizations that promotes worldwide proprietary, industrial,
and commercial standards.
PDO
Payment Data Object
A data object that holds all transaction data, including:
XML message date (original and enriched)
Relational data
Reference data
GPP PAYplus | System Integration - Single Transactions | Page 65
Term
Description
Rates, fees, errors, and so on
PNL
P&L
Profit and Loss Account
A general ledger account through which the annual net profit or loss of a
business is ascertained.
SEPA
Single Euro Payments Area
A European financial infrastructure that creates a zone in which Euro payments
(or any other agreed upon currency) are considered domestic.
SWIFT
Society For Worldwide Interbank Financial Telecommunications
A member-owned cooperative that provides the communications platform,
products, and services to connect over 8,600 banking organizations, securities
institutions, and corporate customers in more than 208 countries.

Navigation menu