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

Configuration » Part 2.
In this lesson I am going to describe
Auto Repair
Debit Authority
Warehouse
For a payment to be processed, number of internal activities need to happen
on the payment. The activities are listed and each of them are impact payment
processing in a specific way. This is explained in detail as we proceed.
TPH has now been Integrated with external Automated Repair Engine - STeP
using Integration Framework
STP Payments in TPH can now be sent to Auto Repair Engine – STeP for
Enrichments based on Rule Engine built inside STeP. This would facilitate
automatic repair of STP Payments with Erroneous Inputs reducing manual
Intervention and thereby Increasing the STP Hits
TPH has the ability to send Payment Instruction Details to an external Auto
Repair Engine - STeP for enrichment and then take the enrichments back and
continue processing the Payment Instruction.
When enrichment happens, it should be possible for the User to see the
changes introduced in Audit Trails. The return codes indicating the nature of
enrichment should be visible in an Audit Trail and they should be available for
decisions on repair-fees
Integration of TPH with External Automated Repair Engine STeP will help
reduce the % of manual Interventions for STP Payments
Example 1 of Auto Repair
Example 2 of Auto Repair
This flow explains how TPH is integrated with Payments Repair.
First Level to enable Automated Repair Functionality in TPH is to have
Programs Per Weight Configured for STP Payments. Depending on the
requirement, User can enable it for Heavy Weight Payments Or Light Weight
Payments. Programs Per Weight Records for both Heavy Weight and Light
Weight is delivered for Automated Repair with Program Skip Indicator as ‘N’
which means Automated Repair Tool is enabled. The user has to Authorize
these records to complete Programs Per Weight Setup. If Automated Repair
Functionality is not required for STP Payments, then set Program Skip
Indicator as ‘Y’. (Please note that Programs Per Weight Records are
Company Specific and this procedure has to be repeated for the Companies
that require Automated Repair Functionality)
Purpose
The Debit Authority component is responsible for verifying whether authority
can be granted to payments for which the debit party is in the books of the
processing bank. This is to prevent fraudulent behaviour from third parties as
they have to specify the correct debit party/account in the payment message.
By interpreting various payment characteristics the DA component is able to
determine whether authority can be granted to the transaction.
Overview
Debit Authority is required for a Credit Transfer for which the debit party
resides in the books of the processing bank requires a valid netting
agreement. A netting agreement is a 3-party agreement between the sending
bank, the processing bank and the customer. It states whether another bank is
allowed to request a payment transfer, or send a payment instruction,
specifying the debit account of the customer that is serviced by the processing
bank. It is the responsibility of Debit Authority to validate whether the party
requesting a payment transfer, or sending a payment instruction, has the
authority to mention a specific third party as the debit party for the payment.
Direct debits will use DD.MANDATE to record and use mandates.
Netting Agreement
Store the netting agreements which usually state which sender of the payment
instruction has the authority to mention a third party as the debit party for the
payment here. Whenever a message type of a company is not specified under
NoDA list, a lookup is performed on this table for the type of message
received from the specific sending bank. The agreement also holds the exact
debit account in the processing bank for which a debit instruction can be
carried out by the sending bank.
NoDA List
Define the list of message types of a company which do not require any
authority to be processed here. If a record is present in this table, the payment
will be authorized straight forward. If not, the transaction is not authorized
directly. Rather the transaction is subjected to further processing such as a
look up for valid agreements between the sending bank and the processing
bank to authorize such payments.
NoDA List
If a record is present in this table, the payment will be authorized straight
forward. If not, the transaction is not authorized directly. Rather the transaction
is subjected to further processing such as a look up for valid agreements
between the sending bank and the processing bank to authorize such
payments.
PURPOSE:
The purpose of Debit Party Determination in TPH is as follows.
• Determine the correct debit account based on the information contained
with the debit parties present in the payment instruction. If the account is
already determined, the process is skipped.
• Pass debit account details to Account and Customer interface for
validation.
• Interpret and update the payment file according to the output returned by
the Account and Customer interface.
• Delete debit charge details only on request from STP flow.
OVERVIEW:
Debit Party Determination ensures that the right debit account is assigned in
the payment file. If the debit account is already determined, the determination
process can be skipped and the account can directly be validated with the
Account & Customer database.
This component plays a very important role in the payment flow as the
determined debit account will be used for determining the message
characteristics of the payment (e.g. client agreement with Bank and payment
charges) and also for booking the transaction amount against the debit
account in the General Ledger.
As the name implies, the next step is to determine the party to be debited.
For instance, when processing a 103, it is imperative to note that the ordering
party has already been debited in the books of the ordering party’s bank.
When the 103 reaches us, we need to know whom we need to debit in our
books.
A 103 can be sent to us directly from the sender or it can be sent via various
parties as listed below.

While determining the debit party, system will always check if the nearest
party to the receiver is the actual party to be debited. Hence, will check

If a Third party reimbursement institution is present in the message in tag 55A,

then, he is the party to be debited. Search for debit party ends here.
If Receiver’s correspondent is present in the message in tag 54A, then, he is
the party to be debited. Search for debit party ends here.
If Sender’s correspondent is present in the message in tag 53A, then, he is the
party to be debited. Search for debit party ends here.
If the account of the sender is present in the message in tag 53B, then, that is
the account to be debited. Search for debit party ends here.
If none of the above is present, then, sender of the payment (Which will be
available in the header) is the party to be debited.
Whenever a BIC is determined as the debit party (In cases 1,2, 3 and 5), it is
assumed that the determined debit party has either a LORO or a NOSTRO
relationship with us. Hence, we extract the appropriate account for the BIC and mark
that as that as the debit account.
In our case, as part of the message, we neither have 55A, nor 54A, nor 53A nor 53B.
Hence, system would extract the sender from the message header and obtain the
LORO/NOSTRO account of the sender
To determine the debit party, no specific configuration is required expect the definition
of the appropriate LORO or NOSTRO accounts (using table
PPL.LORONOSTROACCOUNT)

It is also possible for payments to come in with a forced debit party/account. This is
done during the mapping phase of the payment. In such a case, validation of the debit
account is what is required rather than determining the debit account.

Validating a debit account :

Account exists in PPL.LORONOSTROACCOUNT
Account exists in the DDA
Account is active and not closed
Account does not have any debit posting restrictions
Store the accounts of the correspondent banks with which the bank shares a
LORO and NOSTRO relationship here. This table is linked with the BIC table.
As the BIC table is company specific, this table is also company specific. This
table is also used in the credit account determination step.
PURPOSE:
Bank Conditions or Correspondent bank conditions, define the way in which a
payment should be processed in the payment engine for a correspondent
bank.
Bank conditions of the correspondent bank involved in the payment will
influence mainly Straight through processing of the payment in the payment
engine. This will also allow customizing banks’ charge account, statements
and advices.
The Bank conditions component allows the behaviour of the payment engine
to configure at a flexible level where debit or credit party (or both parties) in
the payment is a bank.
In simple terms, the scope of the Bank conditions is to define the conditions
for warehouse, advices, charge account, statement narrative in postings and
STP flow.
OVERVIEW:
• Special conditions can be agreed and applied on the payments for specific
sending or receiving banks when payments are received from or sent to
them respectively.
• The bank can have a generic conditions and/or Service Level Agreement
(SLA) based conditions with the correspondent banks.
• Bank conditions can be applied at a number of different levels, ranging from bank
(BIC) code to combinations of bank, specific SLA’s and transaction currency.
• If no agreement exists between the banks then default bank conditions will be
applied on the payment.
• In case of customer transfer, bank condition will be applicable for the bank side of
the payment where bank is involved.
CompanyID : It is the company code for which the Bank Conditions record is
created.Valid value from PP.COMPANY table .
CorrespondentBIC : This field refers to the BIC corresponding bank (Sender
or Receiver).
Currency Code : It refers to the transaction currency of the payment. Valid
value from PP. Currency table OR ‘*’ (‘*’ value means it can match all the
currency code).
Start Date Bank Conditions : It is the date from when this record is active.
Credit Special Instruction : It defines the text that will be displayed on the
repair screen when the payment is in repair queue. This text in this field will be
displayed when bank conditions is read for the receiving bank (credit side).
Debit Special Instruction : It defines the text that will be displayed on the
repair screen when the payment is in repair queue. This text in this field will be
displayed when bank conditions is read for the sending bank (Debit side).This
field can only be filled when BTRNonSTPIndicator is set to ‘N’
LanguageID : This indicates the language the corresponding bank would like
to have the statement narratives (including charge description) in SWIFT
advice and account statements. If this field is empty, then the language
defined at company level will be used. Valid value from PP.LANGUAGE table
or blank.
CreditStmtFormatName : This field indicates the preferred statement format to use
when the corresponding bank’s account is credited. Statement format defines a set of
statement narratives that will be used when an account is debited/credited in the
ledger. If this field is empty, then the statement format defined at posting line level or
company level (if not defined in posting scheme) will be used. Valid value from
PP.STATEMENT.FORMAT OR blank.
DebitStmtFormatName : This field indicates the preferred statement format to use
when the corresponding bank’s account is debited. Statement format defines a set of
statement narratives that will be used when an account is debited/credited in the
ledger.If this field is empty, then the statement format defined at posting scheme or
company level (if not defined in posting scheme) will be used. Valid value from
PP.STATEMENT.FORMAT OR blank.
FXSpread : This field defines the preferential rate to be used while determining the
spread for a currency exchange. The rate mentioned is a percentage of the standard
spread.
EndDateBankConditions :It is the date till when this record is active.
ChargeAccountIndicator : This field indicates that Bank requires separate charge
account or charge accounts for different transaction currency. This field is only
required for GUI validation. It is not stored in database.Y or N
TransactionCurrency : This field indicates the currency that will be the transaction
currency for the payment. Valid entry in PP. Currency table or ‘*’
ChargeAccountCompanyID : This field indicates the company ID of the Charge
Account Number defined.
This should be a valid record in the PP.COMPANY. Input to this field can only be
provided if Separate charge Account Indicator is set to Yes
ChargeAccountNumber : This field indicates the account number from which the
charges has to be collected.
ChargeAccountCurrency : This field indicates the currency of the Charge Account
Number defined. This should be a valid currency code. If left blank, this will be wild
carded.
AdviceIndicator : This field provides details on the applicability of AdviceIndicator Y
or N
SequenceNumber : This field is system generated
DebitCreditAdvice : This field indicates whether a debit or credit or Charge Advice
confirmation needs to be generated.

D(debit)
C(credit)
CH(Charge Advice)
Input to this field can only be provided, if Advice Indicator is set to Yes
CTRBTRIndicator : This field defines the transfer type of the payment.
Transfer type can be customer or bank transfer.
C - Customer Transfer
B - Bank Transfer

InitiatedByOthers : This field indicates if Advices are generated by Bank Conditions

or can be initiated by others.
Y (Yes)
N (No)
B (Both)
AmountCurreny : This field indicates the currency that is associated with the amount

FromAmount :This field along with ToAmount field indicates the amount range of the
transaction for the product.
This field indicates the start amount of the range.
Number must be defined.
Default : 0
ToAmount :This field along with FromAmount field indicates the amount range of the
transaction for the product.
This field indicates the end amount of the range.
Range is defined in the transaction currency
Number must be defined.
Default : 999999999999999.00
DeliveryMethod : This field indicates through which channel advice can be sent to
customer
SWIFT / POST/ EMAIL / PHONE / FAX / SMS
Telephonenumber : This field holds the phone number, used for confirmations
Input to this field can only be provided, if Advice Indicator is 'Yes' and Delivery
Method is 'Phone'
EmailID : This field holds Email address to send advices to customer through Email
Input to this field can only be provided, if Advice Indicator is 'Yes' and Delivery
Method is ‘EMAIL’
BICAddress : This field holds the valid BIC
Input to this field can only be provided, if Advice Indicator is 'Yes' and Delivery
Method is ‘SWIFT’
SMSNumber : This field holds Phone number to send advices to customer as SMS
Input to this field can only be provided, if Advice Indicator is 'Yes' and Delivery
Method is ‘SMS’
FaxNumber : This field holds Fax Machine Number to send advices to customer
through FAX.
Input to this field can only be provided, if Advice Indicator is 'Yes' and Delivery
Method is ‘FAX’
PostName : This field holds the street address2 and advices generated will be sent
to through Postal
Input to this field can only be provided, if Advice Indicator is 'Yes' and Delivery
Method is ‘POST’
PostAddress1 : This field holds the street address3 and advices generated will be
sent to through Postal
Input to this field can only be provided, if Advice Indicator is 'Yes' and Delivery
Method is ‘POST’
PostAddress2 : This field holds the street address4 and advices generated will be
sent to through Postal
Input to this field can only be provided, if Advice Indicator is 'Yes' and Delivery
Method is ‘POST’
PostAddress3 : This field holds the street address4 and advices generated will be
sent to through Postal
Input to this field can only be provided, if Advice Indicator is 'Yes' and Delivery
Method is ‘POST’
Attention : Indicates useful information relating to the delivery methods and the
person whom to contact.
E.g. In case of a Phone confirmation, the attribute can hold information on the name
of contact and the preferred contact time and/or the language.
AllowSpecialCharacterSet : This field indicates if special characters are allowed Y
or N
CodePageSet : This field specifies against which code page the special characters
have to be validated.
The value inputted by the user in this field will be validated against the
ASCII.VAL.TABLE
Possible Values:
STANDARD.SW for LATIN or STANDARD.GR for GREEK
Banks provide Customers / Corporates an opportunity to schedule future
payments in advance. These payments are held by the bank and processed in
time, honouring the future date as requested by the customer.
The customers get the dual benefit of scheduling a future payment in advance,
along with the flexibility to cancel / make changes to these payments (until the
actual due date).
There are some Clearing systems which do not accept future dated payments
and some which only accept payments certain days in advance. (E.g. EBA
does not handle future dated payments and TARGET2 can only handle
payments up to 5 days in advance).
In such cases, even though the payment has undergone complete payment
processing and is booked in the Ledger, payment message cannot be sent to
the clearing system to avoid rejection.
In both the above scenarios, the payment engine has to undertake the
responsibility of housing these payments. Warehouse functionality within the
payment hub that holds these payments that need to be processed at a future
date.
How does Dates impact Payment Warehousing?
Payment Warehousing is performed when the payment has a future
Requested Due Date or Requested Credit Value Date.
The difference between these two dates can be explained with the help
of an example as below.
Requested Due Date
Example : On 7th July, start of MediaMarkt wants to schedule the
payment of its invoice received from Dell computers on 7th July 2012.
On 1st July, a payment instruction is created which is scheduled to be
executed on 7th of the Month (Thus 7th July = Due Date). The payment
engine will send this payment to the warehouse.
day, payment is released from warehouse for further payment
processing.
Requested Credit Value Date
Example :2 Albert Hein (AH) has ordered a shipment of 30,000 boxes of
Kiwi fruit from a supplier in New Zealand. The shipment will happen only
when the payment is made available in the supplier’s account on 7th
July (Thus 7th July = Credit Value Date).
On 1st July, a payment instruction is created. The bank has to ensure
that payment reaches suppliers account on 7th July. Therefore, payment
engine processes the payment until routing and settlement is chosen for this
payment (as opposed to warehousing it initially)
When does Payment Warehousing executed for a Payment?
Payment Warehousing is usually called for payment which consists future due date.
As explained earlier, Payments with a Future Requested Due Date will be
warehoused immediately on understanding that customer has requested a
future execution date. i.e. Customer requests for payments with future due
date are always warehoused.
And, Payments with a Future Requested Credit Value Date will be processed to
an extent, so that R&S is able to figure the route, which is then taken into
consideration while defining the Due Date / Credit Value Date.
In both the cases, such Payments are parked with Payment Warehouse.
Also, these payments will undergo complete STP re-processing as and when they are
released from the warehouse.
Why does a Payment released from Payment Warehouse needs to
undergo STP re-processing?
The reason being that, during the time the payment was in warehouse, certain
payment processing information could have undergone change for e.g. the static data
(BIC table), client condition, R&S agreements etc.
Thus, it is important to process these payments again.
When does Output Warehousing executed for a Payment?
Payments which are already processed by the payment engine and the
corresponding posting entries are booked with future send date are mainly
warehoused as the particular output channel does not accept future dated
payments.
Example 3,
V&D is a customer for SNS Bank in Netherlands. V&D initiates a cross border
payment to Germany. However, SNS Bank does not have cross border payment
system. They forward all their payments to ABN AMRO Bank (AAB) for processing.
The agreement with SNS bank is that, all payments will be processed and booked as
and when received by AAB (no warehousing)
AAB receives the payment request on 2nd July from SNS bank with a requested CVD
of 10th July. AAB process the payment until routing and settlement.
R&S figures out that payment is to be sent via EBA. However, EBA does not accept
payments with CVD later than today. In such scenario, payment message cannot be
sent today to EBA to avoid rejection.
Hence, payment is processed and booked today (2nd July = Book Date) but the
payment message will only be sent on the requested CVD.
These payments are directly released to the Output Warehousing component.
How Debit Bank Conditions are associated with Warehouse?
The decision to warehouse payments varies from bank to bank.
A bank may choose to use the warehouse functionality for all payments or only
for certain payment types.
Bank Condition decides whether to warehouse payments or not
If Bank condition says NO Warehousing, then payment will never fall in
warehouse
Release of Payment from Warehouse
On the exact Release Date (i.e. Processing date / Send date), payments are
released back to the respective payment engine flows / components.
Release of Payment to STP Flow
When the Processing Date <= Current Business Date of the processing
company, At SOD the payment is released from warehouse back to the STP
flow.
Release of Payment to Payment Flow / Output Generation
When the Send Date = Current Business Date of the processing company, At
SOD the payment is released from warehouse back to Payment flow.
User can enable/disable the ware housing by setting up the parameter
Warehouse Indicator. Allowed values are
Yes (Y) – Payments are warehoused if the requested credit value date or
requested execution date is in future. This parameter is applicable for all
example 1 explained above. If the parameter is set to Yes, payment will
immediately be warehoused at the start of payment processing, if the request
execution date or requested credit value date is in future.
No (N) – Payments are not warehoused at all.
Just in time (J) – Payments are warehoused after calculating the credit value
date (After the routing and settlement) and if TPH determines the processing
date as future to meet the requested credit value date. This parameter is
applicable to example 2 and 3.
The above configuration can be set for a specific correspondent Bank or for all
the corresponding banks using a default record (By setting the corresponding
BIC/NCC as *).
The send date of the payment message (Output message generation and
delivery) can be setup using the parameter Send Date Base, This application
can be set up for a source and channel combination.
If there is not source and channel combination then TPH will use the default
(*) record for all payments.
The allowed values for the parameter Send Date Base are
DVD – Payment message is sent out on the debit value date, which means on
the date when the money is debited from the debit account.
CVD – Payment message is sent out on the requested/calculated credit value
date. This will be applicable only when the warehouse indicator in Bank
conditions is set to No.
Due – Payment message will be sent out on the Processing date or due date.
This will be applicable only when the warehouse indicator in Bank conditions
is set to No.
Warehoused payments will be released on the start of business day by a
service dedicated to release the warehoused payments. The payment would
follow the same flow as normal payments from then onwards.
Release of Payment from Warehouse
On the exact Release Date (i.e. Processing date / Send date), payments are
released back to the respective payment engine flows / components.
Release of Payment to STP Flow
When the Processing Date <= Current Business Date of the processing
company, At SOD the payment is released from warehouse back to the STP
flow.
Release of Payment to Payment Flow / Output Generation
When the Send Date = Current Business Date of the processing company, At
SOD the payment is released from Send Date warehouse back to Payment
flow
User can perform the below actions on the warehoused payments.
Viewing the Warehouse payment details:
User can click on View icon to view the details of the payment.
Amending the Warehoused Payments:
User can click on Amend icon to amend the details of the payment.
Cancelling a warehoused payment:
User can click the cancel icon to cancel the payment, which will be submitted
to supervisor approval for cancellation.
Force releasing a warehoused Payment:
User can click on to force release the payment from warehouse queue for
payment processing. That means when the user force releases a payment,
payment will be sent to further processing (STP).
In this lesson I described
Auto Repair
Debit Authority
Warehouse
Take a example of the above transfers, you need to calculate the Credit value
date and identify whether the payment will be warehoused or Not. Note that
current business date is 14/11.

RED- Requested Execution Date

RCVD- Requested Credit Value Date
WH Flag – Warehouse Flag Indicator
SS – Settlement Shift
FXS – FX Shift
CS – Cut off Shift
PD – Processing Date
CVD – Credit value Date