Welcome to Payments Temenos Payments Hub, Lesson 5, Static Data

Configuration » Part 3.
In this lesson I am going to describe
Balance Check
Processing of payments
Purpose
Balance Check, as the name suggests, is considered as a vital
component as it is imperative for the Bank to ensure that the Debit
account has enough funds for the payment to be processed.
If the required balance is available for the transaction then the DDA
(Demand Deposit Account) carries out a Reservation on the Debit
account.
This Reservation implies that the Transaction amount is earmarked for
the payment.
Balance Check

The Balance Check Component within the payment engine covers the
functionality for two major facets
Funds Authorization
Funds Authorization is the process of checking whether the Debit
Account has enough funds for the payment to be processed and if
present then Reserving (Earmarking) the funds for the same.
Cancel Reservation
 Cancel Reservation is the process of removing a reservation that is already
applied on an account. This is required when a payment is Cancelled and it
has a valid reservation applied on the debit account. Or in cases wherein the
debit account is changed and the old debit account had a reservation applied
on it.
Note!
The check for Debit Authority and Debit Party determination is completed
before the call to the Balance Check Component. Balance Check Component
will use the debit account determined by Debit Party Determination for the
Reservation.
Funds Reservation is the process of checking if an account has sufficient
funds to perform a debit posting on an account. If the account is found to have
sufficient funds, then the requested amount is ‘earmarked’ or ‘reserved’ on the
account, so that it is utilized when the account is debited, typically at a later
point in time.
Funds Reservation is an integral part of payment processing flows in TPH.
Some examples are below
Credit Transfers: Funds reservation is attempted on initiator’s (debtor) account
during Credit Transfer Initiation (outward)
Direct Debits: Funds reservation is attempted on receivers Account (Debtor
Customer) when a direct debit collection request is received from another
bank
Funds reservation is always attempted before debit posting. The funds
reservation may be attempted on the same day as debit posting, or at a much
earlier time or day. Example, for a same day payment, funds reservation and
posting are performed one after other successively, while for future dated
payments they may occur on different days. These are characteristics of the
payment processing workflows that are configured in TPH as per bank’s
specific requirements.
Funds reservation is usually an automated step in the payment process.
However in the case of insufficient funds the approval can involve a manual or
automated process, at the end of which the request will be either be approved
or rejected. The payment cannot proceed until the approval or rejection is
received.
Field highlighted in the above TPH payment created the Locked amount in
AC.LOCKED.EVENTS. The Record Id for AC.LOCKED.EVENTS is Balance
Reservation Number of the payment.
Handling Insufficient Funds:
In the event of lack of sufficient funds in the account to make a successful
reservation, user can opt for following options in TPH
1) Move the reservation request for manual authorization. In such case, a
supervisor, typically a Credit Officer in the bank, is required to authorize the
reservation. Authorization may involve providing over-draft on the account
2) While the reservation request is waiting for manual authorization, allow
system to automatically retry the reservation at predefined intervals, for a
predefined number of times or until a specific time of the day, or indefinitely
until funds are available. For details refer section “Funds Reservation - Auto
Retry”.
In the event of funds reservation failing due to insufficient funds, system can
be configured to automatically retry the reservation. Retry can be configured to
attempt at a predefined interval in a predefined frequency.
Following configurations are to be set for the desired payment
* Set an appropriate business rule in Admin screen “Balance Check Required”
and set Balance Check Required Flag as Y, see section “Enabling or
Disabling Funds Reservation”
* Set an appropriate business rule in Admin screen Manual Approval for No
Funds under parent menu Balance Check GUI with Manual Auth flag to ‘Y’
* Configure “Allowed Approval Code” to “Recycler” in Account Funds
Authorization Type configuration screen (ACFA.TYPE) for following
configuration records
PP*01 – Insufficient funds
PP*03 – Insufficient funds and account restrictions.
* User can configure the following auto-retry parameters in RC.CONDITION,
RC.TYPE and RC.CAPTURE screens.
* Retry Attempts – Number of retry attempts to be made
* Frequency – use can define recurring frequency, example – every working
day
• Cut-Off date and time - Date and Time until which system will retry for funds
 reservation. The Cut-off date and time set in TPH will be used if available.
If the Auto-retry operation
Succeeds - payment continues its processing in STP mode
Fails - payment will be rejected or cancelled (depending on payment type which is not
configurable by end user, example instant payments are always cancelled).
The above diagram explains the process flow of Balance Check performed in
Payments Hub.
TPH, when processing payments, has the capability to reserve the transaction
amount on the debit account and then execute the various rules based
payments processing. This capability to reserve the balance in an account can
be controlled based on configuration and can be switched off too. For
instance, it would not be required to perform balance check and reserve
balance on a Nostro account if it is the debit account.
Balance Reservation is currently done for the Transaction Amount converted
to the Debit Account Currency using mid-rate. If the debit account and the
transaction amount are in different currencies, a mid rate is applied and
balance is reserved. Balance is reserved by sending a request to the DDA.
DDA then validates the account (checks for restrictions), checks for balance
availability and if available, reserves the balances and returns the reservation
key. TPH then processes the payment and after posting the accounting entries
for the account, unwinds the reservation keys.
User need to create a business rule with one or more of the following
payments attributes that meets the business requirement. Funds reservation is
enabled or disabled for those payments based on Balance Check Required
Flag (Y or N).
* Company – User can create Funds Check rules only for his own Company,
i.e. the T24 Company where he/she belongs. User’s company is defaulted on
the screen and cannot be modified
* Rank – User can set a rank for TPH to prioritize the business rule. In the
event there are two business rules matching a given payment, the one with
higher priority is used.
* Source - User can decide if the payment has to undergo Balance check or
not based on the source of the payment. For instance if the payment is
originated from Payment Order Application he can choose not to perform
balance check since it possibly is already performed in Payment Order
Application
* Account Type – Payment’s mid-office user can perform transactions between
Bank’s Suspense account for adjustments or he can transfer balances from
one PL account to another. In such instances, user can choose not to perform
the balance check on the account. For such scenario’s he can skip balance
check by setting appropriate ‘Account Type’ in this field
* Message Type – User can also skip / perform balance check based on the message
type that is being processed. For instance, skip balance check for the return
messages that is being processed
* Clearing Nature Code – Clearing Nature code is a generic field that carries a certain
attribute of the payment that is assigned (when a payment is loaded into TPH) for a
given payment type. Example it can be chosen as Local Instrument Code in case of
Instant Payments, whereas purpose code for near real instant payments. The
assignment is configurable in TPH, and typically one of the very important attributes
of the payment are chosen here.
User can use Clearing Nature Code as one of the parameters to choose to perform
Balance reservation or Not.
Following are additional characteristics that can be set as part of funds reservation
functionality
Reserve with charges - User can choose to perform funds reservation inclusive of
charges, i.e. single reservation is made for the sum of Payment amount and
applicable charges on the Debtor, or just the Payment amount (i.e. no reservation for
any applicable charge amount).
OE Repair Reservation – For payments that are initiated from TPH Order Entry
screen, the instance when the balance check has to be performed is defined here.
User can choose to perform balance check during
* Payment initiation – funds are reserved when user submits the payment. If funds
cannot be reserved due to some reason, override is displayed on the screen that user
can override
* Authorization – funds are reserved when supervisor authorizes the payment. If funds
cannot be reserved due to some reason, override is displayed on the screen that user
can override
* Within the STP payment processing flow – funds are reserved at the point in the
workflow where funds reservation activity is configured for the given payment type.
See Payment Workflow section for details.
The configuration also applies when to perform funds reservation during payment
repair.
Note: If system is deployed in stand-alone mode, Funds Reservation must always be
configured to be performed “Within the STP payment processing flow”.
Cut-Off Date and Time – This parameter is applicable only if the funds reservation is
configured for automatic retries in the event of failure due to insufficient funds. The
parameter defines the Date and Time until which system will retry for funds
reservation. The date and time configured here overrides the date and time set in T24
Recycler module, see Configuration section for details.
Hold Balance for Future Processing Date – User can choose to hold the funds
reservation for a future dated payment during warehousing by configuring “Y” in this
field. He can take a decision based on the following associated fields.
Approval Code – Based on Approval code user can cancel or retain the funds
reservation. Approval code is the way in which the funds are reserved. So based on
mode in which funds were reserved, either “Manual Authorization “or “Recycler “or
“Blank” (meaning reserved during STP) user can configure the action to be performed
on the payment.
Action – Based on Approval code user can choose to retain the funds reservation or
cancel the funds reservation.
FX threshold is defined in PP.COMPANYPROPERTIES
FX premium or discount is defined in PP.COMPANYPROPERTIES.
If balance check has been configured to be done along with charges, then,
this configuration allows us to define the following
1. If a separate charge account is used for charges, then, should balance
check be done on the charge account
2. Note – If separate charge account is not configured and balance check is
to be done with charges, then, this field will have no significance. Debit
account will be checked to see if there is sufficient balance for transaction
amount plus charges.
This is configurable using Admin screen named “Client Agreements” under
parent menu “Client Conditions GUI”.
Manual Auth Required List
Define the Manual Auth Reqd Flag based on the characteristics of the
payment such as Business Line, Originating Workflow, Originating Source,
Message Priority, Banking Priority, Transaction Amount Limit, Incoming
Message Type and Clearing Nature Code here.
The Manual Authorization Required flag is not checked for Funds
Authorization requests with a Pre-Authorization key. Such requests are never
sent for manual approval within the DDA.
If this flag is set to ‘Y’ then a Manual Authorization can be requested within the
DDA if the debit account does not have the required balance for the
reservation to go through.
If this flag is set to ‘N’ then a Manual Authorization cannot be requested even
if the debit account does not have the required balance for the reservation to
go through. Such a payment would get a ‘Reject’ response
The entries in this table are searched for a match in the order of its Ranking.
The Manual Auth Reqd Flag is retrieved from the first entry that matches the
payment characteristics. If no entry meets the match criteria then a default
value of ‘Y’ is considered.
Auth Required Flag (Y or N) determines if the payment is made available for
manual authorization or not. User can choose to set the rule based on a
variety of payment attributes
* Business Line – Based on customers profiling by the bank, user can choose to park
the payment in Manual Authorization queue.
* Banking Priority – Message priority of the payment. Example, bank can choose to
subject only high priority payments for manual authorization using this flag.
* Tran Amount Upper Limit – User can choose to move the payment for manual
Authorization only if the payment is above a certain amount limit
* Originating Workflow – Restrict manual authorization only when payment is received
in STP mode or manually captured in TPH Order Entry screen
Reject Response Action
Defines the Reject Response Action Flag based on the characteristics of the
payment such as Business Line, Originating Workflow, Originating Source,
Message Priority, Banking Priority, Transaction Amount Limit, Incoming
Message Type and Clearing Nature Code here.
The Reject Response Action flag is not checked for the responses received
against a Funds Authorization requests with a Pre-Authorization key.
If this flag is set to ‘R’ then the payment for which a Funds Authorization
response of ‘Rejected’ is received is to be sent to Repair.
If this flag is set to ‘C’ then the payment for which a Funds Authorization
response of ‘Rejected’ is received is to be sent for Cancellation.
The entries in this table are searched for a match in the order of its Ranking.
The Reject Response Action flag is retrieved from the first entry that matches
the payment characteristics. If no entry meets the match criteria then a default
value of ‘R’ is considered.
Note that the fields in this table are the same as the entries for the Manual
Authorization Required table. Defining a new table for Reject Response action
(and not using the same as Manual Authorization Required) gives the user an
ease in operationally maintaining the tables
When a payments lands in the queue for manual approval, the officer can
approve the overdraft or can choose to reject/cancel the payment.
Pre-authorisation key can only be used for OE and Repair payments as it
needs the key to be keyed-in. It cannot be supplied as part of a message.
When the account is insufficient funds the system throws override before you
commit the record.
When we try to process the payment with transaction amount greater than
pre-authorization key amount than system will throw an error stating “Pre-
Authorization Key is insufficient. Account could be overdrawn in case balance
is insufficient.”
In this lesson I described Messages
Balance Check
Processing of payments
23

This workshop is to understand how to create a Pre Authorization Request.

Pre authorization key is created

Copy this reservation Key which will be used to process Book transfer.
26

This workshop is to understand how to capture a book transfer using a Pre

After committing the record, the entry has to be verified with another user.
32
33

Run a service
34
35
36
37

This workshop is to understand how to capture a book transfer with Insufficient

Authorise the transaction in another user

The status of the payment is moved to 49 due to insufficient funds.

The payment has to be manually approved and authorised for capturing book
transfer.
44

Approve the manual request

Run service
46
47

The lock is created for the manual approved funds and the key is
automatically captured in book transfer.