Introduction to Transaction Recycler

The RC.TYPE application allows the definition of application interfaces to the Transaction Recycler. These application interfaces defined using this table drive the business logic and help the Transaction Recycler carry out the retry processing. For every retry attempt on a settlement account, the transaction recycler transits through different stages (prioritisation, processing, and post process).  It is possible to build an application interface for each of the states, as applicable.

Using this application, it is possible to define core and local routines. These routines are triggered by the transaction recycler service to perform transaction-specific processing. A link to the RC.CONDITION table is specified, which defines the processing conditions for corresponding transaction.

The following fields (in RC.TYPE) are used to determine whether a core routine or a local routine is required to do the processing:

These fields may be set to Yes or No. If set to Yes, System checks to ensure the routine exists.

The following fields are used to determine if any local routines are invoked. These fields may be set to Yes or No. If set to Yes, system checks to ensure the routine exists:

The Loc Cap Chk Rtn field facilitates the application or local routines to decide if the capture of a transaction is allowed. This is an optional field.

• If the value is set to Yes, during RC capture processing, the system will check if a routine with the name RC.CAPTURE.CHK. <RC.TYPE.ID>.LOC exists in the system. If the routine exists, the system invokes this routine to decide if the transaction is eligible for capture or not. If this returns (determined using the return parameter value) CAPTURE.FLAG=FALSE), then this would override core’s capture flag and the transaction will not be captured.
• If the value is set to No or null, the local capture check routine is not invoked.

This application is used to define the accounting entries needed for recycling.

The typical entries captured are:

• Debit entries against a customer account, where funds are unavailable and the account would move into debit.
• Funds authorisation requests sent by TPH in case of insufficient funds and or posting restricts.
• Payment order in case of insufficient funds.

Certain types of customer account or certain transaction types require capturing.

The record ID is a valid code on EB.PRODUCT application.  If different options at lead company level are required, in addition to the EB.PRODUCT ID, the lead company code is added.

When an RC.CAPTURE record is defined for a specific business application, it is possible to specify different retry conditions for different types of requests sent by the business application. For instance, the system accepts any system ID, that is, business application identified by the ID of the record followed by a sub-type.

Using the optional Prod Cat Start and Prod Cat End fields, it is possible to define category ranges of the entries that are to be included. Only entries belonging to the defined category range are considered and rest are excluded.

Therefore, a record with ID as IC is configured to capture entries for the category range 1001 to 1002.

It is possible to use the Txn Code field to configure the system to capture the entries for specific transaction codes. If the field is left blank, the system captures all the entries raised for that System Id. For instance, in the above example, a transaction code is entered in the Txn Code field. Therefore, only those entries matching this code are captured. This field can be sub-valued to include multiple transaction codes.

The System Id and Rc Type are mandatory fields. The System Id should be a valid ID in the EB.SYSTEM.ID application belonging to this product and Rc Type is a valid record in the RC.TYPE application.

This application allows the user to define recycling rules, with each record containing details of a particular set of retry conditions. Various records are created to determine multiple sets of retry conditions.

It is possible to set number of retry attempts in the Retry Attempts field for the Transaction   Recycler to try for recovery of the charge. Otherwise, a period may be specified in the Retry Period field. Either the Retry Attempts field or Retry Period field should be specified (both the fields cannot be specified). In the above example, the frequency has been setup as ‘Every working day’ in the Retry Fqu field and a period of one month is specified in the Retry Period field. This means that the Transaction Recycler will try to recover the cost every day for a period of one month.

The Retry Options field determines whether partial repayment is allowed or not. There are two options:

• Partial – Each time the system attempts to settle the outstanding amount, if the full amount is not available, the system considers the funds to the extent available for settlement.
• End Partial – Each time the system attempts to settle the outstanding amount, if the full amount is not available, then the system does not consider anything until the final attempt. For the final attempt, if the full amount is not available, the system considers funds to the extent available for settlement.

This is applicable for IC application.

The Trans Type field is used to refer the record ID from the FT.TXN.TYPE.CONDITION application. The Transaction Recycler uses this record when generating the FUNDS.TRANSFER to settle a transaction.

The StartDt Option field is an optional field. The field specifies a relative date or a specific day of a month. This is used to offset the START.DATE of the retry process with base date set to capture date. The value of this field can either be given as NN, that is, the actual day of the month or +NN, that is, number of days added to the capture date. Otherwise, it can be set as any numeric value between 1 to 99 when preceded by + character. If the field is blank, by default the START.DATE is assumed as the date on which the transaction is captured within the RC framework. 

The Date Convention field decides the action for the system when RC date (start, end or next retry date) falls on a holiday. It moves the date to next working date or to the previous working date. The valid values are Forward or Backward and the default value is Forward.

The Online Retry Attempts field provides the ability to setup the system to increase the retry attempt or not to, every time the recycler process is run online. As the online recycler retries the requests based on new triggers (new credit on the account, posting restrict set or lifted) or cut off time, it is ideal to set this field as No.

The RC.PRIORITY application is a highest level prioritisation parameter that allows to setup priority of transactions at the company level by EB.SYSTEM.ID or AA.PRODUCT.GROUP. This application is used in conjunction with RC.PRODUCT.PRIORITY and RC.CONTRACT.PRIORITY to create the rules regarding which type of transaction takes priority when there is more than one outstanding transaction against a settlement account. It ranks by EB.SYSTEM.ID, by AA.PRODUCT.GROUP or by a custom RC.PRODUCT.PRIORITY record and the ID to this application can be either a master or a lead company.

In the RC.PRIORITY application, the order of priorities are defined in the descending order (for example, the first definition has the highest priority and so on).

• In the above screenshot, the system is set up to consider the transactions in the following order, if multiple retry requests are posted against the same account:First: Products defined in the RC.PRODUCT.PRIORITY application in the PRIORITY+ONE record (direct debits sent by TPH with transaction code 125).

• Second: Products defined in the RC.PRODUCT.PRIORITY application in the MORTAGES record (MORTGAGE AA Product and then MORTGAGE.CASHBACK AA Product).

• Third: Products defined in the RC.PRODUCT.PRIORITY application in the PRIORITY +TPH record (direct debits sent by TPH with transaction code 213).

• Fourth: Request posted by the PAYMENT.ORDER application, irrespective of the request type.

When using as a priority, either a System ID (an EB.SYSTEM.ID record), the system does not require a correspondent RC.PRODUCT.PRIORITY record. If the RC.PRODUCT.PRIORITY record is not defined, it will process all retry transaction requests posted by the application in a default order, considering the oldest one received by the recycler first.

Def Prev Settle is a filtering rule that means if, out of a list of ‘n’ pending transactions, one of transactions could not be settled (during retry), then all subsequent pending transactions in that list will be abandoned. It could be set to either Yes or No or left blank. If selected, it is applicable for EB.SYSTEM.ID, AA.PRODUCT.GROUP or Product Priority. This field is mutually exclusive with Prev Settle field.

The Prev Settle field can be set as Yes or No. If set to Yes, during retry of ‘n’ transactions, all transactions must be settled. Even if one of the transactions fail for some reason, then none of the remaining transactions will be considered for settlement.

The RC.CONTRACT.PRIORITY application is used in conjunction with RC.PRIORITY and RC.PRODUCT.PRIORITY to create the rules regarding which type of transaction takes priority when there is more than one outstanding transaction against a settlement account. The RC.CONTRACT.PRIORITY is used to set the ranks at transaction level for the same type of retry request. It is used to set priority by value date, transaction amount or by a custom setting, for example by bills overdue status sent to Recycler by Arrangement Architecture (AA).

For example, if there are several transactions for the same product type against the settlement account then the transactions may have to be prioritised.

• The oldest transactions are processed first.
• If there are more than one transaction due for the same date and type, then prioritise by the largest amount first.

The RC.CONTRACT.PRIORITY application allows the user to define sorting priority criteria based on custom values. For example, based on bills status issued by AA in case of loans repayments. To perform this, the Due Type field must be set to ’Sort By Priority Attribute’ value, Due Rule field must be set to Custom and the multi-valued Custom Priority Rank field must contain custom values in the order which they must be sorted. The Custom Priority Rank field must contain valid EB.LOOKUP record values.

In the example below, the custom values represent the overdue bill’s status as they are sent by AA to Recycler, to process the retry requests.

The overdue status is shown in the RC.DETAIL record after the request is settled.

For example, if the Payment Rules are setup to consider the oldest bill first for an AA Product, and for the same AA Product, the contract priority rule is setup to consider the largest amount first (different setup than in Payment Rules), the system works as follows:

• If two bills are issued for the same contract on the same date, the system settles the bills by date (oldest one first) ignoring the ‘By amount’ setup in the Recycler.
• If two bills are issued for the same contract on different dates, the system settles the bills considering the ‘By amount’ setup in the Recycler.
• If two bills are issued for different contracts on different dates, the system settles the bills considering the ‘By amount’ setup in the Recycler.
• If two bills are issued for different contracts on the same date, the system settles the bills by date (oldest one first) ignoring the ‘By amount’ setup in the Recycler.

The user can define product priorities based on contract custom criteria using the RC.PRODUCT.PRIORITY application. If the user wants to define such priority, the Rank Based Priority field must be defined with the RC.CONTRACT.PRIORITY custom name. If this is set, the order defined in RC.CONTRACT.PRIORITY is applied to all products setup in RC.PRODUCT.PRIORITY. For example, it is possible to define custom priority criteria based on bills overdue status and based on product type. The bills overdue status should be setup first in the RC.CONTRACT.PRIORITY application as a custom record (read the RC.CONTRACT.PRIORITY for more details).

In order to sort the retry request based on the setup in RC.CONTRACT.PRIORITY and the one in the product order defined in RC.PRODUCT.PRIORITY, Priority Execution field must be defined. The values in this field are ’Rank Then Product’ and ’Product Then Rank’.

If the value ’Rank Then Product’ is selected, if more than one retry request is posted against the same account, the system orders requests based on the rank (status) defined in RC.CONTRACT.PRIORITY first and then by the product as defined in RC.CONTRACT.PRIORITY. If the value ’Product Then Rank’ is selected, the system orders the requests by product first and then by their rank from the RC.CONTRACT.PRIORITY application.

Example

The following screenshot shows the RC.PRODUCT.PRIORITY is created with the value ’Rank Then Product’.

The RC.CONTRACT.PRIORITY custom record ‘MORTGAGELOANS’ has the setup as shown in the below screenshot.

The RC.PRODUCT.PRIORITY record is setup to order the requests according to the rank (status) first and then according to the product order (MORTGAGE.LOANS.USD and then MORTGAGE.LOANS.1Y), if more than one request has the same rank (status).

In case the RC.PRODUCT.PRIORITY record has a custom ID and if the Priority Execution field is defined with the value ’Rank Then Product’, the Aa Product Group field will become multivalued, allowing the definition of priorities based on products which are part of different AA PRODUCT GROUPS in the same record.

The input of Aa Product Group field is mandatory in case any Aa Product are defined. The Aa Product definition is not mandatory if the Aa Product Group is entered. If only the Aa Product Group is defined, the system considers all the retry requests posted by any product type within the product group and orders them by date (the oldest one is considered first). It is not possible to define a duplicate combination of Aa Product Group and Aa Product of the same type in the same record.