Introduction to Transaction Restriction

The TZ.TRANSACTION.STOP.PARAMETER allows the bank to define:

• Default Expiry Days (for the stop instruction) – If Default Expiry Days is parameterised here and if Expiry Date is not captured in the instruction, the Expiry Date is automatically set at the authorisation of the stop instruction. The Default Expiry Days is added to the current business date to determine the expiry date. Maximum allowed is 999W or 999C.
  • If this field is set to 90C, then the Expiry Date in the TZ.TRANSACTION.STOP.INSTRUCTION is calculated by Core Banking as the current business date plus 90 calendar days.
  • If this field is set to 90W, then the expiry date in the Transaction Stop Instruction is calculated by the Core Banking as the current business date plus 90 working days.
  • If this field is blank, it is not defaulted by Core Banking.
• Days to History – This field indicates the number of working days after which a cancelled or expired stop Instruction is moved to history (max 99W).
• Dup Stop Criteria –This field allows the bank to indicate a duplicate criteria (defined via Temenos Transact standard duplicate check feature – EB.DUPLICATE.TYPE application) that is applied when a transaction stop is created to verify if the same transaction stop instruction is already entered.

When a new transaction stop instruction is entered or amended, the system verifies the appropriate record in the TZ.TRANSACTION.STOP.PARAMETER table. If a duplicate stop criteria (EB.DUPLICATE.TYPE) is indicated here, the duplicate validation is triggered. Before the details are passed to EB.DUPLICATE table, the attribute names are ordered alphabetically to ensure the duplicate check does not depend on the order of the stop attributes in the stop instruction.

The following screenshot shows the TZ.TRANSACTION.STOP.PARAMETER.

The following instructions are setup on Account 12345678:

According to the Dup Stop Criteria defined earlier, these two instructions are actual duplicates, though the order in which the attribute name, operand and values indicated in the instruction is different.

The TZ.TRANSACTION.STOP.TYPE table allows the bank to define stop types (usually per source or channel) to specify various matching types. One or more matching types can be defined by combining attributes which once matched, the stop instruction is considered satisfied, irrespective if not all of its criteria are actually met.

For each matching type, a default decision on how to handle a transaction that matches at least one instruction are also defined here:

• Return – The transaction is rejected
• Pay – The transaction is posted

The rules defined here are evaluated in order. A stop is found when a match type is met. The default decision of the satisfied matched type is considered and the next match type rule does not get verified.

Consider that the stop instruction on Account 12345678 has the following stop criteria:

• Amount Equal 100.
• Party Name Equal ABC company.

An ACH transaction REF123 is received and evaluated against the rules defined in this. The transaction is on the Account 12345678, amount 200, party name is ABC Company and party identifier is AB123456.

The amount and the party identifier in the transaction does not match the amount in the stop instruction. Party identifier is not part of the stop criteria and therefore the first match type in the ACH record is not satisfied. The next match type is based on party name. As the party name in the transaction and stop instruction is equal, the second match type is satisfied and the default decision of this match type is to reject the transaction.

Another ACH transaction REF129 is received and evaluated against the rules defined in the ACH record. The transaction is on the account 12345678, amount 100, party name is XYZ Company and party identifier is XY123456.

The amount and the party identifier in the transaction does not match the amount in the stop instruction. Party identifier is not part of the stop condition and therefore the first match type in the ACH record is not satisfied. The party name in the transaction and stop instruction is different and therefore the second match type is not satisfied. The amount in the transaction and stop instruction is equal and therefore the third match type is satisfied and transaction is paid.

In both cases, an investigation item is created for the bank user to monitor the exceptions and take a decision.

TZ.TRANSACTION.STOP.CONDITION parameterisation table can be used when the bank wants to impose limitations on the stop criteria, which can be captured in the stop instruction. For example, stop by cheque number and amount. The stop condition, once indicated in the stop instruction, validates that the stop criteria input by the user is aligned with the rules imposed by the bank.

Example

The following condition record indicates that for the stop criteria in the instruction, it is mandatory to have cheque number and amount and the operands allowed for each of them.

Based on this setup, when a stop instruction is initiated by the user and the Stop Condition is ’Stop by Check Number and Amount’, the Stop Criteria is auto-populated from the Stop Condition.

If the Stop Condition is left blank, the user can select the attributes from those which are defined in the DEFAULT record in TZ.TRANSACTION.STOP.CONDITION.

TZ.TRANSACTION.STOP.MAP.RULES parameter table defines the sources to which a transaction stop check applies.

The above record shows the setup for transactions initiated though the Generic Accounting Interface (OFS Clearing), posting rule for local clearing (LCLG – the ID of the AC.ENTRY.PARAM record).

A qualifier condition is added to indicate that only specific transactions received through this interface are checked against stop instructions (in this example, if Transaction Code = 1).

The channel or transaction type, which is assigned to these transactions, is defined in the Stop Type and are used:

• To identify the stop instructions that apply to these transactions.
  • A Stop Instruction for a transaction type = ACH applies to a transaction received from this source.
  • A Stop Instruction with transaction type left blank applies to all transactions received from all channels.
  • A Stop Instruction for a transaction type different than ACH (for example, cheque and DD) cannot apply to a transaction received from this source.
• To identify the TZ.TRANSACTION.STOP.TYPE record which defines the matching criteria and the default decision.

The Account field indicates the field in the transaction’s business application (identified in Application Name) from where the account is extracted.

In the above example, the account number in AC.INWARD.ENTRY table stores the account where the funds are posted, the active stop instructions on this account is retrieved. The matching attributes and rules on how to extract them from the transaction’s business application are defined in Matching Attribute and Attribute field Extract fields.

In the above example, Amount Lcy is a core field in AC.INWARD.ENTRY but Party Name and Party Id are local fields in the same application.