You are here: Retail Banking > Transac on Recycler

Transac on Cycler (Retail)

Introduction
Purpose of this Guide
This user guide describes the Transaction Cycler that provides the ability to retry failed financial transactions at regular
intervals.

Intended Audience
This user guide is intended for the use of internal Temenos users and clients.

Overview
Transaction Cycler provides the ability to retry failed financial transactions at regular intervals. This is a generic retry
mechanism which can be consumed by any T24 application. Currently this is restricted to handle IC and AA transactions.

Retry of failed transactions would be done using a recycler T24 service, which would run as a COB job in a specific stage
both during END.OF.DAY and START.OF.DAY. This job would retry the transactions on scheduled dates until the
transaction is settled or number of retry attempts allowed have been exhausted or retry end date is reached.
During each retry recycler would take the amount available in the settlement account for settling the transaction amount
in full or partial based on the recycler retry configuration setup.
If a transaction handed over to RC is settled outside of RC framework, then, those transactions would not be considered
for further processing by RC and would be marked with a specific status

Existing IC processing of interest and charges to accounts

Interest and charges module has no retry option on its own and it currently utilizes the core override suspense processing
to avoid any IC transaction getting posted to the settlement account. Using the suspense processing, customer account
would be replaced with an internal suspense account in core accounting stages. The transaction amount would be parked
in that internal account. The actual debit/credit to the customer account would be stopped at this stage and whenever
status of the settlement account improves, manual intervention is required to check and debit/credit the settlement
account.

Existing AA settlement processing

Settlement processing allows definition of a settlement accounts to a Loan or a Deposit arrangement. AA could settle Bills
(Payments) that are made due automatically by taking funds from the Settlement Account. During the settlement
process, the account specified to settle bills may or may not have sufficient funds for the purpose. Values FULL, PARTIAL
and NONE in the PAYIN.RULE field controls the settlement process in such cases, using the ACCOUNT.DEBIT.RULE
1. Full – Se le the bill in full by overdraw the account.
2. Par al – Take the available amount in the account and make remaining as Due.
3. None – Don’t take anything from the se lement account if it cannot se le the bill in Full.

In the Settlement processing, if the bill is made due and not settled from the settlement account due to insufficient funds
in the account, there should be a mechanism to retry them in the future.
Setup consideration specific to AA
AA PAYMENT / PAYOUT rules order / sequence setup has to be in sync with the setup done in recycler priority setup
tables, that is, if oldest bill setup is done in AA payment rules, then, recycler contract priority should also be set in the
same order.
Work low
Settlement processing through RC consists of two steps.
Se lement Handoff to RC
Transac on Retry

Settlement Handoff to RC
AA Bills Made Due Online
Bills made due online would be se led immediately.
Se lement processing would happen only if ‘Auto se le’ is enabled for the bill generated.
When the se lement account has enough funds to se le the bill in full, then bill would be se led immediately.
When there are no sufficient funds, an override is raised so that the user could decide if they s ll want to go ahead with make-due even though
Se lement would not happen.
When RC is configured in se lement product condi on then the bill details would be handover to RC.

AA Bills Made Due during COB

During COB when bills are made due AA se lement processing would be skipped and handover the bill details to RC ONLY if RC configured in se lement
product condi on.

Interest or charge capitalized to an account during IC COB

As part of IC.COB job, on the capitaliza on date, any interest or charges posted to a savings/current account and if due to any override suspense processing,
these entries are not posted to the underlying account, then, recycler would check if the transac on parameters are suitable for retry by recycler. If so, IC
would handoff the transac on to recycler for further processing
Transaction Retry
Transaction cycler would retry the failed transactions of a given settlement account during Close of Business through the
job RC.CYCLER.SERVICE, both during START.OF.DAY and END.OF.DAY stages.
Every failed transaction would be retried both during EOD and SOD stages and would count to one attempt.
For COB transactions, when a transaction is handed over by the application to RC, it would be retried on the same date
and at the same stage.
For online transactions, if online settlement fails, then these would be picked for retry during that day’s EOD stage.
Subsequently, each failed transactions would be retried both during SOD and EOD stages of cycler job.
Selec on –RC.DETAILS records is selected and grouped by se lement account. I.e. A single record is passed with all the transac ons, which has to be
processed by a se lement account.
Pre-process - Se lement account is verified and applica on pre-API is called to get the outstanding due amount for each transac on.
Priori se – Prior se the selected transac on. Availability of funds in the se lement account is checked against each transac on due amount and also as per
COMBINED.BY.DATE se ng.
Process – Process each transac on and call OFS.CALL.BULK.MANAGER. When transac on is failed the last retry status is marked as failed.
Post Process – Loop through each transac on selected and for each transac on, applica on specific post API is called to get the status of the processed
transac on and update the return status in RC.DETAIL.

RC.TYPE
The table RC.TYPE allows us to define the application interfaces to the transaction cycler. These application interfaces are
purpose built business logic that can help the transaction cycler do the retry processing. For each retry attempt for a
Settlement Account, the recycler transits through different states (Pre, Prioritisation, Process, and Post Process). An
Application Interface could be built for each of the states as applicable.
This table is used to define the core and local routines that will be called by the transaction cycler service to perform
transaction specific processing. It also provides a link to the RC.CONDITION table which defines the processing conditions
for this type of transaction. This is released as a part of core itself.
Loc Post Process - This field defines whether a message specific API routine is called by the cycler to perform
processing after the transaction has completed. Valid options are Yes/No. This field is a mandatory input.
‘YES’ indicates that a core priority processor rou ne needs to be called. The rou ne name will be built up as “RC.POST.”:RC.TYPE:”.LOC” key

Loc Pre Process - This field defines whether a specific local routine needs to be called to preprocess a message. For
example, to get the current due amount for transactions where the amount due is not fixed and could change based on
the values. Valid options are Yes/No. This field is a mandatory input.
‘YES’ indicates that a core pre processor rou ne needs to be called. The rou ne name will be built up as “RC.PREP”:RC.TYPE:”.LOC” key

Loc Prioritise - This field is used to define whether a message specific local routine to be called by the cycler to perform
transaction grouping and sorting. For example to order and group AA bills for a particular arrangement based on AA
product rules, e.g. combine all bills for a particular date and to sort by date order. Valid options are Yes/No Null.
‘YES’ indicates that a core priority processor rou ne needs to be called. The rou ne name will be built up as “RC.PRTY.”:RC.TYPE:”.LOC” key.

Post Process - This field defines the message specific API routine to be called by the cycler to perform processing after
the transaction has completed. Valid options are Yes/No. This field is a mandatory input.
‘YES’ indicates that a core priority processor rou ne needs to be called. The rou ne name will be built up as “RC.POST.”:RC.TYPE key.

Pre Processor - This field is used to define whether a message specific core routine need to be called to pre process a
message. For example to get the current due amount for a transaction, where the amount due is not fixed and can
change with time. Valid options are Yes/No. This field is a mandatory input.
‘YES’ indicates that a core pre processor rou ne needs to be called. The rou ne name would be built up as “RC.PREP.”:RC.TYPE key For example
RC.PREP.AC.FIXED for fixed amounts such as charges or debit interest against the se lement account. RC.PREP.AA.DUE for overdue AA bill processing.

Prioritise - This field defines the message specific core routine to be called by the cycler to perform transaction grouping
and sorting. For example, to order and group AA bills for a particular arrangement based on AA product Payment rules,
e.g. combine all bills for a particular date and to sort by date order. Valid options are Yes/No.
 ‘YES’ indicates that a core priority processor rou ne needs to be called. The rou ne name will be built up as “RC.PRTY.”:RC.TYPE key.

Processor - This field defines the message specific core routine to be called by the cycler to process the cycler
transaction, or transactions if they are grouped. For example to settle all AA bills for a particular date, to collect a flat
amount of interest or charges due from a current account. Valid options are Yes/No. This field is a mandatory input.
YES indicates that a core priority processor rou ne needs to be called. The rou ne name will be built up as “RC.PROC.”:RC.TYPE key.

RETRY PROCESS
RC.CONDITION
This table contains details of the recycling rules, with each record containing details of a particular set of retry conditions
Retry Frequency - Standard frequency field used to determine the frequency at which the RC should retry from the
settlement account for an outstanding bill.
Retry Attempts – Defines the number of retry attempts that RC should try before giving up, it would be number of days
if frequency is daily.
Retry Period – Defines a specific period, for example to terminate the retry processing based on the date the
transaction was added to the recycler. For example,
M0131 end of this month,
M0231 end of next month,
M0215 on the 15th of the next month. This field is no input, if a Retry attempt is set.
Retry Options - This field is used to determine whether partial or End Partial.
PARTIAL - During each retry date, system a empts to se le the transac ons par ally with the funds available in the se lement account, if sufficient fund is
not available to se le it fully.
END.PARTIAL – During final retry date, system a empts to se le the transac on par ally with the funds available in the se lement account, if sufficient fund
is not available to se le it fully.

This is applicable for IC application.

Retention Period - Defines the number of days that the RC.DETAIL record would remain after maturity before being
deleted or moved to history
Write to History - This field is to indicate whether RC.DETAIL record would be written to the RC.DETAIL.HIST file. ‘YES’
indicates that the RC.DETAIL record will be written to RC.DETAIL.HIST after the post maturity period. “NO” or NULL
indicates that the detail record will be deleted at the end of the retention period.
Txn Type – This field is used to specify an FT.TXN.TYPE.CONDITION ID and would be used by recycler while generating
FT entries to settle a transaction.
Prioritisation Parameters
The prioritisation rules are for sequencing the pending transactions for a given Settlement Account.
There are three linked tables
RC.PRIORITY - Ranks transactions by EB.SYSTEM.ID
RC.PRODUCT.PRIORITY - Ranks by product within an EB.SYSTEM.ID
RC.CONTRACT.PRIORITY - Ranks at transaction level

RC.PRIORITY
This is a highest level prioritisation parameter that allows setup of priority of transactions used to set priority at the
company level by EB.SYSTEM.ID or AA product group
This application contains the rules regarding which types of transaction take priority where there is more than one
outstanding transaction against a settlement account. It ranks by EB.SYSTEM.ID.
The id to this table should be either a master or lead company
AA.PRODUCT.GROUP – This field is used to define the AA.PRODUCT.GROUP.
DEF.PREV.SETTLE – It is actually a filtering rule that means if, out of a list of’ n’ pending transactions, if one of them
could not be settled (during retry), then all subsequent pending transactions in that list would be abandoned. It could be
set to either Yes or No or left blank. If selected it is applicable for EB.SYSTEM.ID of for AA.PRODUCT.GROUP. This field is
mutually exclusive with PREV.SETTLE.
Allowed values are “Yes” or “No”
When set to YES, during retry of ‘n’ transactions, all transactions must be settled. Even if one of them fails, for some
reason, then, none of the ‘transactions’ should be considered for settlement.
All these transactions can be on different value dates.
Examples
Transac on 1: Se lement of payment due bills of an arrangement A1 whose Product Group=Mortgages
Transac on2: Se lement of charge due bills of an arrangement A2 whose Product Group=Mortgages
Transac on3: Se lement of charge due bills of an arrangement A10 whose Product Group= Mortgages

Therefore, in this case, if DEF.PREV.MUST.SETTLE=‘YES’, then, if settlement account has sufficient balance to settle
transactions 1, 3 and not 2 then, none of them should be considered for settlement processing.
When set to ‘NO’ or ‘blank’, if funds are available for only one transaction out of 3, system would process it.
PREV.SETTLE – It is actually a filtering rule that means if, out of a list of’ n’ pending transactions, if one of them could
not be settled (during retry), then all subsequent pending transactions in that list would be abandoned. It could be set to
either Yes or No or left blank. If selected it is applicable for EB.SYSTEM.ID of for AA.PRODUCT.GROUP.
When set to YES, during retry of ‘n’ total transactions having transactions under the same EB.SYSTEM.ID or
AA.PRODUCT.GROUP id, then, all transactions must be settled or if one of them fails, for some reason, then, none of the
transactions would be considered for settlement. All of these transactions could be on different value dates.
An example involving AA transaction is as below,
 Transac on1: Se lement of payment due bills of an arrangement A1 whose product group=Mortgages
Transac on2: Se lement of charge due bills of an arrangement A1 whose product group=Mortgages
Transac on3: Se lement of payment due bills of an arrangement A2 whose product group=Home Equity

Transactions 1, 2 and 3 would form 2 groups = Mortgages and Home Equity and that would be taken for applying the
rules separately. Therefore, for 1, 2 if transaction 1 has sufficient funds from the settlement account and transaction2
does not have sufficient balance, then none would be selected for settlement. If one of the transactions is not settled
(during retry), then all the subsequent pending transactions in that list would be abandoned.
An example involving IC transactions is as below,
Transaction1: Debit interest capitalised on account AC1 on 31st May 2013 is captured (IC4)
Transaction2:Charge capitalised on account AC1 on 05th June 2013 is captured by RC (ICGC)
Transaction3:Debit interest capitalised on account AC1 on 02nd June 2013 is captured by RC (IC4)
Current processing date is 06th June EOD. The priority of settlement would be Transaction 2,1 and 3. Within the
transactions 1 and 3, transaction 3 would not be taken for processing until transaction 1 is completed, since
PREV.MUST.SETTLE is enabled for IC4 type of transactions as shown in the above screen shot 2.

RC.PRODUCT.PRIORITY
This is the next level of prioritisation within each of the T24 Product Code or AA Product Group defined in RC.PRIORITY.
This application contains the rules regarding which types of transaction take priority where there is more than one
outstanding transaction against a settlement account. It ranks by product within an EB.SYSTEM.ID.
The ID to file can be either an EB.SYSTEM.ID or AA.PRODUCT.GROUP
Ex, Mortgage product may take precedence over Mortgage Cash back product.
AA.PRODUCT - This field is used to define the priority in order of AA product group. For example In Mortgage Product
group Mortgage would be the first priority and Mortgage Cash back would be the second priority. It forms a part of the
multi value set with field AA.CONTRACT.PRT
AA.CONTRACT.PRT - This field is used to link to the transaction level priorities that have been set up in the application
RC.CONTRACT.PRIORITY and would be applied to the AA.PRODUCT. It forms a part of the multi value set with field
AA.PRODUCT. It must be a valid record of RC.CONTRACT.PRIORITY
PROD.CAT.START / PROD.CAT.END – These are associated multi valued fields used to specify the range of category
codes for prioritizing the recycled transactions. When recycler service decides the priority of processing the transactions
under a given settlement account, for all non-AA transactions, It would compare the category code of the account or
transaction with this range and decide the priority.
CONTRACT.PRTY – This field is used to link to transaction level priorites that have been set up in the application
RC.CONTRACT.PRIORITY and would be applied to any Non-AA transactions processed by the recycler.

RC.CONTRACT.PRIORITY
This is the lowest level of prioritisation to specify the prioritisation characterised by the individual arrangements on which
the transactions are pending.
This application contains the rules regarding which types of transaction take priority when there is more than one
outstanding bill (transactions) against a settlement account. It ranks at transaction level, defines the priority of
repayment for transactions of the same type for example oldest first.
It is used to set priority by value date and transaction amount, for an AA product.
For example, if there are several transactions for the same product type against the settlement account then they may
need to be prioritised for example
Process the oldest transac ons first
If there is more than one transac on due for the same date and type then priori se by largest amount first.

The following options are available:

COMBINED.BY
DATE
 SORT.BY.DATE
OLDEST
NEWEST
SORT.BY.AMOUNT
LARGEST
SMALLEST

COMBINED.BY Date here means, combining multiple transactions (of the same type) with the same due date and trying
to settle them. If the total cannot be settled, none of them will be settled. This is similar to the Combine Bills in AA with
the exception that, here, only the Due Date and the RC Type are looked at. AA will combine bills only if both Issue Date
and Due Date are same for the bills to be combined.
DUE.TYPE - This field is used to define the a type of priority conditions, which are predefined
Mandatory input field with the following options. It is grouped by
SORT.BY.DATE
SORT.BY AMOUNT
COMBINED.BY
DUE.RULE - This is a predefined list of preferences for each of the values defined in DUE.TYPE. This is a Mandatory input
field. Predefined list of preferences for the for the DUE.RULE
COMBINED.BY – By Date (Due rule)
SORT.BY.DATE – Oldest and Newest (Due Rule)
SORT.BY.AMOUNT- Highest and Lowest (Due Rule)

Note : AA PAYMENT / PAYOUT rules order / sequence setup has to be in sync with the setup done in recycler priority setup tables, that is, if oldest bill
setup is done in AA payment rules, then, recycler contract priority should also be set in the same order.

CAPTURE
RC.CAPTURE
The table RC.CAPTURE is used to configure conditions/rules based on which a transaction could be captured by the
central Accounting engine. i.e., based on EB SYSTEM ID, Category code range, Transaction code etc.
The key to this table should be a valid EB.PRODUCT.ID and optionally could be followed by a lead company code. When a
company code is specified, then, capture conditions are specific to that company alone.
However, this table is only for those Applications that cannot make their own decision on when to hand over a
transaction to the recycler. For example IC. So, an IC transaction would be handed over to recycler at the core
accounting level based on the setup done in this table and there is no rc specific setup done within IC.
The table is used to define accounting entries which need to be captured and stored for recycling.
Typical entries to capture will be debit entries against a customer account where funds are not available and the account
would move into debit. It is possible that only certain types of customer account or certain transaction types need to be
captured. For example all transactions against a savings account that is legally not allowed to go into debit, including COB
based periodic charges; some types of account may go into debit for periodic charges but not for loan repayments or
payments into savings deposits.
LOC.CAPTURE.RTN - This field is used to indicate whether a specific routine is called after the checks defined here to
further determine whether a transaction should be captured. The routine name will be constructed as followed;
RC.CAPTURE":RC.TYPE
PROD.CAT.START - This field is used to define particular product types to be captured by the recycler. For example
Savings accounts could be captured but current accounts could be ignored. It forms part of a multi value set with
PROD.CAT.END enabling a range of category codes to be specified
PROD.CAT.END - This field is used to define particular product types to be captured by the recycler. For example
Savings accounts could be captured but current accounts could be ignored. It forms part of a multi value set with
PROD.CAT.START enabling a range of category codes to be specified.
SYSTEM.ID – This field is used to identify the underlying applications whose entry would be recycled. For example,
AAAA – AA Arrangement Activity.
DEF.RC.CONDITION – This field used to specify the Default RC condition. It could be used when a generic condition is
needed for the product rather than for the individual system id under the product
DEF.RC.TYPE – This field is used to specify the Default RC type. It could be used when a generic RC type definition is
needed for the product rather than for the individual system id within the product
RC.TYPE - This field is used to specify which RC.TYPE record will be used. When this is given it would override the
default value given in DEF.RC.TYPE.
RC.CONDITION – This field is used to specify which RC.CONDITION record would be used. When given, this would
override the default value given in DEF.RC.CONDITION.
SUSPENSE.CATEGORY - This field is used to define the Suspense category for this type of transaction.
RC.DETAIL and RC.DETAIL.HIST
This live table stores the details of each transaction to be recycled.
The table RC.DETAIL holds the information about the transaction that was either captured by the Recycler or was
handed-off to the Recycler by an Application.
The key to this table is made up of the Settlement Account number, Due Date, EB.PRODUCT.ID, EB.SYSTEM.ID or AA
Product Group, Category code or AA Product, and unique serial number or Bill Reference.
The record holds details of the captured contract reference, retry attempts, retry conditions that are applicable to this
transaction.
After settlement RC.DETAILS.HIST would get updated if WRITE.TO.HISTORY is set as Yes in RC.CONDITION
RC.CONDITION – Links the RC.CONDITION reference to a transaction. It would be updated during the capture of the
transaction and would not be allowed for any modification.
RC.STATUS - This field is used to maintain the status of the recycled transaction. A cycler transaction could have various
statuses – For example,
New – A new transac on is capture for recycling and recycler is yet to take it for processing.
Current – Recycler is in the process of retrying to se le the dues of the transac on.
Completed – Recycler has been completed i.e. it has been se led fully or crossed the final retry date.
Rejected – Transac on is rejected for some reasons like – invalid se lement account, AA bill is not valid, AA bill has already been se led outside recycler etc.

RC.TYPE – Linked to RC.TYPE to get API routines.

RETRY.START.DATE – Date loaded in to Recycler

RETRY.END.DATE – End date of the Retry period.

AA.PRODUCT.GROUP - This field holds the product group of the arrangement for the bill in transaction cycler.
AA.PRODUCT – This field holds the product of the arrangement for the bill in transaction cycler.
SETTLE.STATUS – This status indicates the current settlement status of the transaction. The various possible settlement
statuses are:
Pending – No se lement has happened. It would update during capture
Se led – Fully se led – Recycler has se led the transac on fully.
Par al – Par ally se led, during retry if transac on is se led par ally.
Rejected – Transac on is se led outside RC framework.
SETTLE.OPTION – This field would be updated during the capture process and could not be changed after that. It
specifies the option which recycler would carry out when there is insufficient balance in settlement account during retry
process. For AA, it would be a value passed by AA during capture process based on the value set in the settlement
product condition of the arrangement.
FT.TXN.TYPE – Defaulted from the RC.TYPE during capture of the transaction.
LAST.RETRY.DATE – Date and time of last retry date. It could be set only for daily retry.
Last Retry Result – Override/Exception message if last retry was unsuccessful.
ARRANGEMENT.ID – This field is populated with the arrangement id of the bill.

Settlement property class – AA (Arrangement Architecture)

Overview
The SETTLEMENT property class supports selected settlement requirements for Lending, Deposits and Accounts
arrangements. The settlement property class enables the settlement of dues / payouts using another arrangement / T24
Account or creates DD.ITEM by providing DD.MANDATE.REF.
Settlement Property allows settlement of dues / pay-outs between an arrangement and another arrangement / T24
account.
PAYIN.ACCOUNT (Receive) & PAYOUT.ACCOUNT (Pay) can either be a T24 account or an arrangement account.
It allows specifying a drawdown account to receive funds from or specifying a liquidation account to pay funds to.
PAYIN.ACCOUNT & PAYOUT.ACCOUNT can either be a T24 account or an arrangement account (either LENDING or
DEPOSITS or ACCOUNTS arrangement). This property class is also used to link one or more Payment Types in AA to
Direct Debit mandates. This is achieved by linking a mandate defined in the Direct Debit (DD) module to an arrangement
account which is done through this SETTLEMENT Property.
The SETTLEMENT property Class could be used when bills issued are to be settled directly by debiting an account in a
third party bank. This is achieved by linking a mandate defined in the Direct Debit (DD) module to an arrangement
account which is done through this SETTLEMENT Property.
For the direct debit to work, the mandate should have a status of ACTIVE/AVAILABLE. When bills are issued, DD.ITEM
records will be created by the system for the payment types that are specified in the SETTLEMENT property. On the claim
date (the value date of the bill payment), the arrangement account is credited with funds and appropriated according the
rules specified in PAYMENT.RULES property.
When a claim is generated if the transaction code in DD.TXN.CODES for CLAIMED ITEM CREDIT is mapped to an activity
via ACTIVITY.MAPPING, the corresponding activity will be run. This will settle the bills that are made due and will update
the necessary files.
When a claimed item is returned then the repayment activity will have to be reversed and the corresponding files will
have to be reinstated to its initial status.

AA Product Lines
The SETTLEMENT property is used by the following product line:
LENDING
DEPOSITS
ACCOUNTS
Product Property Relationship
The SETTLEMENT product property supports the following arrangement links to the product.
DATED

SETTLEMENT Property Class record

Property Attribute Description and Uses

The settlement property class processes DUE bills with either specifying the T24 Account in PAYIN.ACCOUNT or by
creating DD.ITEM by providing DD.MANDATE.REF. In the settlement property, user has to specify the PAYMENT.TYPEs
based on which bills are to be settled by applying the PAYIN.SETTLE.ACTIVITY. Settlement property will function only if
PAYIN.SETTLEMENT is set to YES.

AA.PRD.DES.SETTTLEMENT record

The Receive Settlement Instructions are meant for funds coming into the arrangement. The PAYMENT.TYPE Field is the
link between Payment schedule and Settlement Property. This can be sub valued for different types of Interest, Charges.
The PAYIN.SETTLE.ACTIVITY Field holds the activity that is run to receive funds, currently APPLYPAYMENT activity alone
is allowed. This settlement activity fetches the settlement account corresponding to the same payment type from the
respective Payment Schedule.
Please note that where there are funds available in UNC, the system would have already settled out of it during MAKE
DUE and the outstanding itself would be only the remaining amount of the bill.
The Active fields for PAYIN.SETTLEMENT can be used with field values YES and NO to switch off and switch on
settlement instructions, without clearing other settlement related fields. This could be to stop a settlement instruction at
arrangement level or to change the customer level settlement instruction for a payment type in the arrangement.
Funds can be received from either a T24 ACCOUNT (Customer / Internal / Nostro) or from a T24 Arrangement or from a
DD mandate. Examples of funds received – Funding of AA Deposit, Repayment of AA Loan, Making an initial deposit for
an arrangement Account, payment of Interest or a charge.
Possible to settle activity charges through settlement property. All Activity Charges are grouped under the payment type
ACTCHARGES. Activity Charges look in the Settlement Property for that payment type and fetches the corresponding
settlement instructions. The Settle Activity is defined in Activity Charges PC. This settlement activity refers to the
AUTO.SETTLE Field of the respective Activity Charges property. If this field is set to YES, then it will look up the
Settlement property and fetch the settlement account corresponding to the same payment type.
PAYIN.AC.DB.RULE can be set as FULL, PARTIAL or NONE. If FULL is set in PAYIN.AC.DB.RULE, then the entire bill of an
arrangement will be settled even when the PAYIN.ACCOUNT has insufficient balance thereby overdrawing the account
when limit is set. If PARTIAL is set in PAYIN.AC.DB.RULE, then the bill of an arrangement will be settled only upto
available balance of the PAYIN.ACCOUNT when it has an insufficient balance. If NONE is set in PAYIN.AC.DB.RULE, then
the entire bill of an arrangement will be settled only when the PAYIN.ACCOUNT has sufficient balance and no settlement
will happen in case of any shortfall of funds in the PAYIN.ACCOUNT. However, PAYIN.AC.DB.RULE can be either PARTIAL
or NONE if the PAYIN.ACCOUNT is an arrangement account reference.
In the settlement property, user has to specify the Property class or property based on which bills are to be settled by
applying the PAYOUT.SETTLE.ACTIVITY. Settlement property will function only if PAYOUT.SETTLEMENT is set to YES.
PAYOUT.PPTY.CLASS is the field that will enable the settlement of PAY balance of any of the properties of that property
class. Whereas, if the property is specified in PAYOUT.PROPERTY, only the PAY balance relating to that specific property
will be settled. (For eg. If there are 2 charges to be paid to the customer, say properties CHARGE1 & CHARGE2 are used,
if CHARGE is specified in the PAYOUT.PPTY.CLASS field, both the charges will be paid and settled to the
PAYOUT.ACCOUNT, but if CHARGE1 alone is specified in PAYOUT.PROPERTY, only the pay bill of CHARGE1 property
alone will be settled towards the PAYOUT.ACCOUNT).
Back-dated adjustments will be handled only when the settlement is from/to another T24 arrangement
PAYIN.RC.CONDITION – Defines the RC.CONDITION to be used for the payment type to allow variation of different retry
conditions. It should be a valid entry in RC.CONDITION.
PAYIN.RC.TYPE – Defines the RC.TYPE to be used during handoff to inform the recycler what type of transaction is being
handed-off. It should be a valid entry in RC.TYPE.
Fields PAYIN.RC.CONDITION and PAYIN.RC.TYPE is available in the “PAYIN” payment type multi value set to define the
frequency and PAYIN.RC.TYPE is used to define the core and local routines that would be called by the transaction cycler
service to perform transaction specific processing. It also provides a link to RC.CONDITION table which defines the
processing conditions for this type of transaction
AA PAYMENT / PAYOUT rules order / sequence setup has to be in sync with the setup done in recycler priority setup
tables, that is, if oldest bill setup is done in AA payment rules, then, recycler contract priority should also be set in the
same order.
PAYIN.ACTIVITY is the activity that will be triggered for sourcing the payment from the PAYIN.ACCOUNT. (For example
DEPOSITS-APPLYPAYMENT-PAYOUT.RULES activity will be triggered to fetch the funds for settling the due bill of the
lending arrangement for which the PAYIN.SETTLE.ACTIVITY will be triggered to apply the payment received).
PAYMENT.TYPE is the payment type that is specified in PAYMENT.TYPE field in AA.BILL.DETAILS.
AA.ARR.SETTLEMENT record
 AA.BILL.DETAILS
For the claim to credit arrangement account and to settle the proceeds of the bills that are made due, the credit
transaction code of DD claimed item should be linked to a repayment activity in AA.
 DD.TXN.CODES for different transactions of DD.
The DD.TXN code for CLAIMED.ITEM is to be linked with a repayment rule as shown below:
 Activity mapping with repayment activity mapped.
The following additional steps are required:
The payment rule which has been created specifically for the direct debit should have the activity LENDING-CREDIT-
ARRANGEMENT in the field REMAINDER.ACTIVITY, such that when the claim is actually processed, the credit will first be
made by the DD module to the unallocated balance of the arrangement account. This should have only the properties of
the payment types defined in the SETTLEMENT property condition of the arrangement. It should not have any additional
properties:
 Rule on how bills are to be settled.
As shown below, the APPLY.PAYMENT field in the Payment Schedule property should be input with the payment rule for
the direct debit. This will result in the AA module appropriating the unallocated balance to the properties specified for
settlement.
 APPLY.PAYMENT field with REPAYRULE1.
Linking DD with Arrangement
After the new arrangement input, the account number of the arrangement is used to create a DD.DDI record (mandate)
to provide a link to the arrangement.
 Arrangement with account number updated.

DD.DDI record for the arrangement account.

The DD.DDI record status should be AVAILABLE to make use of the direct debit functionality to settle the bills. In the first
instance, when the DD.DDI record is created the status will be NEW and after authorisation, the same should be changed
to AVAILABLE.

The mandate created through DD.DDI should be updated in the field DD.MANDATE.REF in the SETTLEMENT property
condition of the arrangement using LENDING-UPDATE-SETTLEMENT activity. The field PAYMENT.TYPE can hold any of
the payment types defined in payment schedule. The field SETTLE.METHOD should be DD.
 SETTLEMENT condition at arrangement level.
During bill issuance, records in DD.ITEM will be created for every payment type defined in SETTLEMENT property with
the contract reference as the AA.ARRANGEMENT.ACTIVITY ID of the issue-bill activity.

Processing of the DD linked to AA

In the example below, the bill is issued 2 days prior to the due date i.e. the due date is on 15th Dec and the bill is issued
on 30th Nov during end of day process (The working days being 30th Nov, 4th Dec, 15th Dec....)
 Payment schedule definition with bills issued 2 days prior to due date.
The issue bill activity triggers creation of DD.ITEM records for the payment types that are mentioned in the SETTLEMENT
property.
 DD.ITEM with status as NEW.ITEM
The status of the DD.DDI record will be NEW.ITEM till the payment is processed. And the contract reference updated is
the respective issue-bill activities for the arrangement for different payment types. Bill is in ISSUED status:
 AA.BILL.DETAILS with bill status as ISSUED
The figure below shows that the status of the bill has been updated after the DD processing on the payment date of the
bill. The DD.ITEM record has status updated to CLAIMED.ITEM.
Bill settled.
 DD.ITEM updated as CLAIMED.ITEM.
Balance Movements
 Movements shown on how DUE balances are settled via UNC balance.

Settlement through an internal account

During the settlement process, system identifies bills to be settled based on payment types that are defined in the
payment schedule for a lending arrangement. These payment types must be given in the field PAYMENT.TYPE.
 Se lement Property for a lending arrangement.

For deposits and savings, the settlement process happens based on property class and properties of the arrangement.
These values must be given in the field PAYOUT.PR.CLASS and PAYOUT.PROPERTY.
In case of settlement of bills using internal account, the account number must be specified in the field PAYIN.ACCOUNT
for lending arrangements and field PAYOUT.ACCOUNT for deposit or savings arrangements. The payment rule that the
system should trigger during the settlement process must be specified in the field PAYIN.SETTLE.ACTIVITY for lending
arrangements and in the field PAYOUT.SETTLE.ACTIVITY for deposits and savings arrangements.
The fields PAYIN.SETTLEMENT and PAYOUT.SETTELEMENT can be used with field values YES and NO to switch off and
switch on settlement instructions, without clearing other settlement related fields.
During the settlement process, the internal account used to settle bills may or may not have the sufficient funds for the
purpose. Values FULL, PARTIAL and NONE in the field PAYIN.AC.DB.RULE control the settlement process in such cases.
1. FULL: System debits the PAYIN account to the extent of the bill amount irrespec ve of whether or not the funds are available in the specified account. For
this purpose, system creates an overdra in the PAYIN.ACCOUNT in case funds are only par ally available provided the PAYIN.ACCOUNT has a limit a ached
to it.
2. PARTIAL: System debits the PAYIN.ACCOUNT only to the extent of funds available.
3. NONE: System would not debit the PAYIN.ACCOUNT if funds are not fully available to se le the bill.
PAY PROCESSING:
The settlement property class processes PAY bills either by specifying the arrangement account reference, the T24
Account in PAYOUT.ACCOUNT or by creating DD.ITEM by providing DD.MANDATE.REF. In the settlement property, the
user has to specify the Property class or property based on which bills are to be settled by applying the
PAYOUT.SETTLE.ACTIVITY. The settlement property will function only if the PAYOUT.SETTLEMENT is set to YES.

PAYOUT SETTLEMENT condi ons for an arrangement

The PAYOUT.PPTY.CLASS is the field that will enable the settlement of PAY balance of any of the properties of that
property class. Whereas, if the property is specified in PAYOUT.PROPERTY, only the PAY balances relating to that specific
property will be settled. (For eg. If 2 charges are to be paid to the customer and properties CHARGE1 and CHARGE2 are
used, if CHARGE is specified in the PAYOUT.PPTY.CLASS field, both the charges will be paid and settled to the
PAYOUT.ACCOUNT, but if CHARGE1 alone is specified in PAYOUT.PROPERTY, only the pay bill of CHARGE1 property will
be settled towards the PAYOUT.ACCOUNT).

PAYOUT.ACTIVITY is the activity that will be triggered for applying payment in the PAYOUT.ACCOUNT. (Eg. DEPOSITS-
APPLYPAYMENT-PAYOUT.RULES activity will be triggered to apply the funds after settling the PAY bill of the deposit
arrangement, for which PAYOUT.SETTLE.ACTIVITY will be triggered to PAY the property PAYBALANCE).
For the below arrangement, interest bills have been issued as shown in the last activity and settlement activities
(CHECK.SETTLE and APPLYPAYMENT) have been triggered to settle the bill. System has used the payout rule mentioned
in settlement property to settle the bill.
 AA ACTIVITY HISTORY

AA.BILL.DETAILS: The bill in the above arrangement has been settled.

 Se led bill through se lement process

Payout account has got the interest credit.

STMT.ENT.BOOK

EB.CONTRACT.BALANCES: PAY balance for Interest property is settled.

 EB.CONTRACT.BALANCE

The settlement process can also be controlled in payment schedule property by giving values as YES or No in the field
AUTO.SETTLE. If the field is set to NO, System would not process bills through settlement property.
 Payment schedule property

For activity charges, settlement process can be controlled in activity charge property by giving values as YES or NO in the
field AUTO.SETTLE in activity charges property. If the field is set to NO, System would not process charge bills through
settlement property.

Ac vity charges property

Exchange Rate Processing

The system provides the facility for foreign currency settlement of bills for an arrangement. The user can have foreign
currency arrangements with local currency settlement accounts and vice-versa. Cross currency settlement can also be set
up where in settlement happens to a foreign currency account/ arrangement from another foreign currency arrangement
with the local currency being a different currency.
For the various currencies used, the user must create event types, AC.ALLOCATION.RULE records should be created as
shown below.
Example Event types:
TAX-MAKE.DUE-DUE-GBP
TAX-MAKE.DUE-DUE-EUR
TAX-MAKE.DUE-DUE-CHF
TAX-MAKE.DUE-DUE-SGD
Action synopsis
Individual AA.PROPERTY.CLASS.ACTION records control which Product Line it’s associated to.
The SETTLEMENT Property supports the following actions:

CREATE.DD
This action is triggered when the DD.ITEM is created during ISSUE-BILL activity.

UPDATE
This action is initiated manually and allows the user to change any of the SETTLEMENT attributes

Configuration
Configuration for Transaction Cycler is shown here for Mortgages and Long term deposits as an example.

Fields PAYIN.RC.CONDITION and PAYIN.RC.TYPE is available in the “PAYIN” payment type multi value set to define the
frequency and used to define the core and local routines that will be called by the transaction cycler service to perform
transaction specific processing. It also provides a link to RC.CONDITION table which defines the processing conditions for
this type of transaction
RC.TYPE
This table is used to define the core and local routines that would be called by the transaction cycler service to perform
transaction specific processing. It also provides a link to RC.CONDITION table which defines the processing condtions for
this type of transaction.
These records will be released by Temenos, but could be modified by the user
RC.CONDITIONS
Different RC.CONDITIONS were created with Retry Frequency and Transaction Type, which could be attached under the
Settlement product conditions.

Comment : If WRITE.TO.HIS is set as “YES”, then if the dues or Funding is settled fully then the record moves from
RC.DETAIL to RC.DETAIL.HIST
Some of the RC.CONDITIONS configured are shown here.
DAILY FREQUENCY

BUSINESSDAY
RC.CONDITION for Deposit products with Frequency set as Business Day with Retry Attempts
RC.CONDITION set for Deposits product with frequency as Business day and Retry period is kept as 7 days.
RC.CONDITION set for Deposits with frequency as Business Day.
RC.CONDITION for Deposits with Daily Frequency
RC.CONDITION for Deposits with Daily frequency and Retry a empts is kept as 7
RC.CONDITION for Deposits set as Daily frequency, and Retry period as 7 Days.
RC.CONDITIONS for Deposits with Retry frequency as Fortnightly
RC.CONDITIONS “ Deposits with Retry Frequency as Monthly
RC.CONDITIONS “ Retry Frequency as Fortnightly
RC.CAPTURE - The table is used to define accounting entries which need to be captured and stored for recycling.
The table RC.CAPTURE is used configure conditions/rules based on which a transaction could be captured by the central
Accounting engine. i.e., based on EB SYSTEM ID
RC.PRIORITY - This table contain the rules regarding which types of transaction take priority where there is more than
one outstanding transaction against a settlement account
RC.PRIORITY created with the product groups included to set the prioritisation level
RC.CONTRACT.PRIORITY
This table contains the rules regarding which types of transaction take priority where there is more than one outstanding
transaction against a settlement account.
RC.CONTRACT.PRIORITY record was created to set the prioritisation level for transaction with DUE RULE set as ‘Oldest’
and DUE TYPE set as ‘Sort by Date’

RC.PRODUCT.PRIORITY - This table contains the rules regarding which types of transaction take priority where there is
more than one outstanding transaction against a settlement account.
Product level priority was set using the RC.PRODUCT.PRIORITY for the product group Deposits and Mortgages.
RC.CONTRACT.PRIORITY created is attached here.
AA.PRD.DES.SETTLEMENT
RC.CONDITION and RC.TYPE is attached under the SETTLEMENT product conditions at product level.
Deal Processing
Result:
Select an existing account or create a new account where account balance could be ‘0’ or very less balance.
Accounts were selected with no balances.
Create a Deposit Arrangement
Input a Deposit arrangement with PAYIN &PAYOUT account as 65277 which had no balance and the commitment amount
for deposit is inputted as 40000.
Note: RC.CONDITION – Frequency is defaulted as DEPOSITS.DAILY in Settlement conditions from Settlement Product
condition.
As the account had no balance deposit account has not been funded.
Bill got generated with status as Expected, as deposit funding was not made.

Check for the RC DETAIL, for the account given in se lement condi ons. The se le status is updated as pending with
Retry start date as 29 Mar 2013.
Creation of Lending Arrangement
Input a Lending arrangement with same account in PAYOUT (65277) and different account in PAYIN (65269) settlement
conditions and the Commitment amount is input as 450,000 USD.
RC.CONDITION is defaulted as “DAILY” (Retry frequency) from the settlement product conditions.

A er authoriza on, auto-disbursement is made to the account 65277 men oned in the Payout Account, but the Due
charges is not se led as PAYIN account has nil balance.
Bill got generated for Ac vity charges NEWARRFEE and with status as DUE, as PAYIN account has nil balance.
RC.DETAIL
Check for RC DETAIL for account specified in PAYIN balances ‘65269’. Since the charges are not settled an RC.DETAIL is
created.
Create a new account
A new account is created without any balances.
Create Lending arrangement without automatic disbursement
Input a Lending arrangement without auto-disbursement with PAYIN account with the newly created account .
Commitment Amount – 40,000. RC.CONDITION – defaulted as ‘DAILY’(Retry Frequency) from the Settlement product
condition.
Comment: Remove the PAYMENT.TYPE –DIBURSEMENT.% from the PAYMENT.SCHEDULE Disbursement, as we are
going to make a manual disbursement it should not have this payment type.
PAYIN account 65323 has no balances. Therefore, Due charges has been created
Bill got generated for Due Charges with status as Due.
Through FT, Disbursement for the arrangement has been done.

Check for RC DETAIL record for new account, a RC.DETAIL is created as the charges are due.
Before Running the CoB, the balances are checked in the respective Payin Account specified in Settlement conditions.
All the Accounts have sufficient balances.
After running the cob, RC detail is settled and moved to history as we have set WRITE TO HISTORY AS ‘YES’
Mortgage Arrangement
View the arrangement after the settlement is made. Bills status is settled.
Lending arrangements

Bills status is se led.

Long Term Deposit
Deposit Arrangement
View the Deposit arrangement after the Bill is settled.

Bill Status is updated as se led.

* Deposit is got funded and expected bill got se led by the system by Transac on Cycler.

Mortgage with Manual Disbursement

View the arrangement a er the se lement is made. Bills status is se led.

Lending arrangements

Bill status is updated as Se led.

*Charge bill is got settled by system through Transaction Cycler.
*** Activity Charges bill will get settled in Lending Arrangement if auto-disbursement was set and same account was
given in both settlement conditions.

Published on: 11/01/2019