Settlement

The Receive Settlement Instructions are meant for funds coming into the arrangement. The Payment Type field is the link between Payment Schedule and the Settlement Property. This can be sub valued for different types of interest and charges.

This field contains the Payment Type (with a valid entry in AA.PAYMENT.TYPE) based on which the repayment settlement instruction is processed. For loans, the payment types are defined in Payment Schedule (ANNUITY, LINEAR, and so on). Apart from the above, other specific types are:

• DEPOSIT.PRINCIPAL - Used to Payin (or fund) a deposit.
• CHARGE – Used to settle Activity charges or Periodic charges.

If the user wants to combine multiple payment types to one settlement account, this field can be sub-valued and all values in the set, can take funds from the account defined in this set.

PAYMENT.TYPE is the payment type that is specified in Payment Type field in AA.BILL.DETAILS.

It is possible to settle activity charges through the Settlement Property Class. All activity charges are grouped under the ACTCHARGES payment type. 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 looks up the Settlement property and fetches the settlement account corresponding to the same payment type.

The Active (Payin Settlement) field is used as a switch, to turn off the settlement instruction temporarily without having the need to clear or delete the field contents. If it is set to No, then it means the instructions are not active.

Account Debit Rule (PAYIN.AC.DB.RULE) can have one of the following values: FULL, PARTIAL or NONE. It can be either PARTIAL or NONE, if the Payin Account is an arrangement account reference.

• FULL: The entire bill of an arrangement gets settled even when the Payin Account has insufficient balance thereby overdrawing the account when limit is set.
• PARTIAL: The bill of an arrangement gets settled only up to available balance of the Payin Account when it has an insufficient balance.
• NONE: The entire bill of an arrangement gets settled only when the Payin Account has sufficient balance and no settlement happens in case of any shortfall of funds in the Payin Account.

It must be a valid record in AA.SETTLEMENT.TYPE.

The Settle Activity (PAYIN.SETTLE.ACTIVITY) field holds the activity that is run to receive funds, APPLYPAYMENT activity is allowed. A user activity can also be stated in this field. This settlement activity fetches the settlement account corresponding to the same payment type from the respective Payment Schedule.

Note that where there are funds available in UNC, the system has to be configured in Applypayment field of Payment Schedule Property Class to settle out of it during make due and the outstanding itself would be only the remaining amount of the bill. 

It contains the account number from where funds are to be debited and credited against this payment type. Multiple accounts can be defined here and the rules of funding are governed by the Account Debit Rule field.

ACCOUNT DEBIT ACTIVITY is the Activity that can be triggered for sourcing the payment from the Payin Account. When Payin Account used is an arrangement account, then an Activity has to be specified to debit that arrangement as well. That Activity needs to be stated here. If the account is not an arrangement account, then this field is not required to be stated since the debit happens directly. Note that this activity happens on the arrangement from which funds are debited and is not relevant to this arrangement. It is only a definition on this arrangement.

For example, DEPOSITS-APPLYPAYMENT-PAYOUT.RULES Activity can be triggered to fetch the funds for settling the due bill of the lending arrangement for which the Settle Activity can be triggered to apply the payment received.

Defines the RC.CONDITION to be used for the payment type to allow variation of different retry conditions.

Defines the RC.TYPE reference to be used during handoff to inform the recycler the type of transaction that is being handed-off.

It has the DD mandate to be used if the settlement method is DD. The DD number must be the account of the arrangement. It has to be a valid mandate ref from DD.DDI.

This field allows the user to define only a percentage value. The system cascades from top-to bottom, down the multiple fields taking the percentages in order (a blank field is considered for processing last). The percentage defined is the percentage portion of the billed amount, which is settled from the respective account. The total percentages may not exceed 100 percent and it may not total 100% (the blank account number at last without percentage indicator collects the remaining amount)

In case of any rounding issues, the last account is the account to process any required adjustments. A blank field can be defined at last, in this case, the remainder of the bill is settled from this account.

This allows to define only a fixed value. The system cascades from top-to bottom, down the multiple fields taking the amounts defined in order (a blank field is considered for processing last). When a bill is generated, the individual amounts or total amounts defined, may exceed the billed amount. That is the case where the amount defined is an up-to amount. This is the maximum that can be taken and honours the Account Debit Rule field. To satisfy the bill, a lesser amount can also be taken. When a bill is generated, the individual amounts or total amounts defined, may not satisfy the billed amount. The amount defined is the amount to be taken. In this case, any remainder of the bill is made due.

This field is linked to the PAYMENT.ORDER.PRODUCT table and its value is passed through to the PAYMENT.ORDER application. Its main purpose is to control parameters for message processing.

• It is an optional field and is used in conjunction with Payin Beneficiary
• It drills down to the PAYMENT.ORDER.PRODUCT table.

• This field is a link to the core BENEFICIARY table and is used to define the debit account. The BENEFICIARY record is mapped through to the PAYMENT.ORDER application.
• When configured a payment order is generated and this can be used to link to an alternative DDA account system. Current functionality also allows for a Temenos Transact account to be defined in the beneficiary record which is debited.

• For an account or deposit with the Counterparty Type field as Payin or Both in the Account condition, the settlement details mentioned in Payin Beneficiary must be one of the Beneficiary in the Counterparty field of the Account condition for that Counterparty Type. When the settlement account defined is not a nominated counterparty, the system raises a validation error.

• It is an optional field with the below features:
  • It is mutually exclusive with Payin Account and RC setup
  • It is used in conjunction with Payin Po Product
  • It drills down to the BENEFICIARY table

If Account Settlement (PAYIN.ACCT.SETTLE) is set to Combined and automatic settlement using Temenos Transact account is defined (irrespective of the settlement instructions whether they are multi-valued or sub-valued), the system combines the due bill amounts and generates a single settlement for the combined amount when the following criteria are met:

• Combine Bills in payment schedule condition is set as Yes.
• Bills are due on the same date.
• Bills are configured to be settled using the same Temenos Transact account (PAYIN.ACCOUNT).
• Same Settle Activity (PAYIN.SETTLE.ACTIVITY) is defined for all the bills.

When this field is not set or left blank, the above functionality is not applicable, and system continues to generate settlement entries based on whether the settlement instructions are multi-valued or sub-valued.

It contains the Property Class based on which the payout settlement instruction gets processed. This definition allows the users to configure multiple payouts happening to multiple accounts. For example, the user can configure interest to be paid out to one account, whilst the maturity deposit amount to be credited to another account. It has to be a valid record in AA.PROPERTY.CLASS.

It contains the PROPERTY based on which the payout settlement instruction is processed. This definition allows the users to configure multiple payouts happening to multiple accounts. For example, the user can configure current interest to be paid out to one account, whilst the maturity deposit amount may be credited to another account. It has to be a valid record in AA.PROPERTY.

This Active (PAYOUT.SETTLEMENT) field is used as a switch to turn off the settlement instruction temporarily without having to clear or delete the field contents. If the field is set to No, then the instructions are not active. Valid input is Yes or No.

Settlement Activity (PAYOUT.SETTLE.ACTIVITY) holds the values on the applicable Activity for payout, when payout of funds has to happen automatically. This is an APPLYPAYMENT-PAYOUT Activity or ones belonging to them. This activity is triggered on this arrangement every time payout happens to another account. It has to be a valid record in INACTIVITY.

This contains the account to which funds are to be credited from this arrangement. It has to be a valid Temenos Transact account number.

The Activity to be triggered to credit the account arrangement, when Account used is an arrangement account, is specified in this Account Activity (PAYOUT.ACTIVITY) field. If the account is not an arrangement account, then this field is not required to be stated since the credit happens directly.

This activity happens on the arrangement from which funds are debited and is not relevant to this arrangement. It is only a definition on this arrangement. It has to be a valid entry in AA.ACTIVITY, and must belong to the same Product line as stated in the Account.

The Account Credit Rule (PAYOUT.AC.CR.RULE) field is to define the user exception routine using the AA.SETTLEMENT.TYPE. It is possible to configure the payment rejection to accounts that are dormant or has posting restrictions. Without such rules being configured, the system completes posting to account that are dormant or has posting restriction. In such cases, we can further have transaction cycler for those transactions to be retried.

RC Condition (PAYOUT.RC.CONDITION) defines the RC Condition to be used for the payout property to allow variation of different retry conditions. For Payout, RC.CONDITION record with Retry option NONE is only allowed.

RC Type (PAYOUT.RC.TYPE) defines the RC.TYPE reference to be used during handoff to inform the recycler what type of transaction is being handed-off.

It allows the ability to define only a percentage value. The system cascades from top-to bottom, down the multiple fields taking the percentages in order (a blank field is considered for processing last). The percentage defined is the % portion of the billed amount, which gets settled from the respective account. The total percentages may not exceed 100% and the total percentages may not total 100%. In case of any rounding issues the last account is the account to process any required adjustments. A blank field can be defined at last, in this case the remainder of the bill is settled from this account.

It allows to define only a fixed value. The system cascades from top-to bottom down the multiple fields taking the amounts defined in order (a blank field is considered for processing last). When a bill is generated, the individual amounts or total amounts defined, may exceed the billed amount. In this case the amount defined is an up-to amount. This is the maximum that can be taken and honours the Account Debit Rule field. To satisfy the bill, a lesser amount can also be taken.

When a bill is generated, the individual amounts or total amounts defined may not satisfy the billed amount. The amount defined is the amount to be taken. In this case any remainder of the bill is made due.

This field is linked to the PAYMENT.ORDER.PRODUCT table and its value is passed through to the PAYMENT.ORDER application. Its main purpose is to control parameters for TPH processing and pass outgoing messages parameters.

• It is an optional field and is used in conjunction with Beneficiary.
• Drills down to the PAYMENT.ORDER.PRODUCT table.

• This field is a link to the core BENEFICIARY table and is used to define the credit account. The record in BENEFICIARY is mapped through to the PAYMENT.ORDER application.
• When this field is configured, a payment order is generated, and this can be used to link to an alternative DDA account system. The existing functionality also allows for a Temenos Transact account to be defined in the beneficiary record which is credited.
• It is an optional field with the following features:
  • It is mutually exclusive with Payout Account and RC setup
  • It is used in conjunction with Payout Po Product
  • It drills down to the BENEFICIARY table
• For an account or deposit with the Counterparty Type field as Payout or Both in the Account condition, the settlement details mentioned in Payout Beneficiary must be one of the Beneficiary in the Counterparty field of the Account condition for that Counterparty Type. When the settlement account defined is not a nominated counterparty, the system raises a validation error.

  

When this Account Settlement (PAYOUT.ACCT.SETTLE) field is set to Combined and automatic settlement using Temenos Transact account is defined (irrespective of whether the settlement instructions are multi-valued or sub-valued), system combines the pay bill amounts and generates a single settlement for the combined amount if all the following criteria are met:

• Combine Bills in payment schedule condition is set as Yes.
• Bills should have the same payment date.
• Bills are configured to be settled using the same Temenos Transact account (PAYOUT.ACCOUNT).
• Same Settle Activity (PAYOUT.SETTLE.ACTIVITY) is defined for all the bills.

When this field is not set or left blank, the above functionality is not applicable, and system continues to generate settlement entries based on the settlement instructions whether they are multi-valued or sub-valued.

The below scenarios illustrate the way the Transaction Recycler prioritises and settles the bills for different set of configurations.

Scenario 1

If the bill is generated for NEWARRFEE and INSTALLMENT, based on the above setup the system prioritises the bills as given below:

1. HOME.EQUITY.LOANS-NEWARRFEE
2. MORTGAGES-NEWARRFEE
3. HOME.EQUITY.LOANS-INSTALLMENT
4. MORTGAGES-INSTALLMENT

It is possible to configure the RC.CONDITION in-line with Settlement Payin Account Debit Rule as to Full or Partial. Consider an example where the RC Condition mapped to Charge does not allow partial settlement of bills, however, Installment bills can be settled partially. Accordingly, RC has not settled the NEWARRFEE bill, while the Installment bill is partially settled based on the available funds in the settlement account.

The details of retry result and if it has failed due to insufficient funds / partial payment not allowed are available in the RC.DETAIL. Also the Rank Info is updated in the RC.DETAIL. In this case, the Rank Info is the bill type and for priorities based on aging status, the respective aging status of the bills is stored.

Scenario 2

If the bill is generated for NEWARRFEE and INSTALLMENT, based on the above setup the system prioritises the bills as given below:

1. HOME.EQUITY.LOANS-NEWARRFEE
2. HOME.EQUITY.LOANS-INSTALLMENT
3. MORTGAGES-NEWARRFEE
4. MORTGAGES-INSTALLMENT

Scenario 3

In this case, if there are two bills of same type (say ACT.CHARGE) then it is:

• Sorted by Product (that is, HOME.EQUITY.LOANS then MORTGAGES)
  • Then by Due Type and Due Rule, in this case,
    • Sort By Date , and then Sort By Amount

Scenario 4

If the bills generated are in NAB and DEL status, based on the above setup the system prioritises the bills as given below:

1. HOME.EQUITY.LOANS-NAB
2. MORTGAGES-NAB
3. HOME.EQUITY.LOAN-DEL
4. MORTGAGES-DEL

Scenario 5

If the bills generated are in NAB and DEL status, based on the above setup, the system prioritises the bills as given below:

1. HOME.EQUITY.LOANS-NAB
2. HOME.EQUITY.LOANS-DEL
3. MORTGAGES-NAB
4. MORTGAGES-DEL

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 the type of transaction that is being handed-off. It should be a valid entry in RC.TYPE.

The Payin Rc Condition and Payin Rc Type fields available in the PAYIN payment type multi-value set define the frequency. Payin Rc Type is used to define the core and local routines that are 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 or PAYOUT rules order or sequence setup has to be in sync with the setup done in the recycler priority setup tables, that is, if the oldest bill setup is done in AA payment rules, then, the recycler contract priority should also be set in the same order.

Multiple Account Definition

Within settlement processing on the Due side individual or multiple accounts can be defined. The Transaction Cycler prioritises the retry of the individual accounts based on the order defined on the settlement record.

For multiple accounts configuration this functionality has limitations. Only the settlement rule of “Partial” with no “Percentage” or “Amount” values defined are allowed.

Retry Processing from Multiple Account

During the life cycle of the arrangement, based on the customer’s request there is a possibility that the user may prefer to change the settlement pay in account. In such a scenario setting the Update Pending Retry field to Yes indicates that the changed account number is considered to settle the existing outstanding overdue bills.

The Update Pending Retry field can have one of the following values:

• Yes - The change is applied to the existing older pending request also.
• No - Then the change is applied only to future bills.

The following limitations are applicable for Update Pending Retry:

• The settlement rule can be set as “partial “or “none”
• Does not apply to the rule “Full “
• Does not apply to percentage being defined.
• Does not apply to amount being defined.
• Does not apply when the Update Settlement activity is future dated. If the user tries to change the settlement account when the Update Pending Retry is set as Yes, then the system should throw the "Pending Retries cannot be updated for future dated activities" error.

The following are the options available for Retry Processing from multiple accounts:

Update

Where there is a change in the payin account number with Rc Type, Rc Condition enabled, Update Pending Retry set as Yes, and the user has updated the settlement activity, and replaced settlement account A with settlement account B the following occurs:

The system creates new pending request on settlement account B, by replicating all the pending request retry characteristics of settlement account A.

• The Take over Date field in RC.DETAIL stores the pending requests created on the new pay in settlement accounts.
• Rc Status on settlement account A is updated as TERMINATED, with a reason: Pay In Account Removed.

Removed

• During the update settlement activity, whenever the Rc Type and Rc Condition is removed from the payin side of settlement account and the Update Pending Retry field is set as Yes, the system removes all the requests linked to the overdue bill passed by AA.
• Rc Status is updated as TERMINATED, with the amend reason: Removed Retry Condition.

Update: Change in Multiple Repayment Account Number

Account(s) are added to the payin conditions, changing the existing pay in order. For example, a loan is paid from settlement account A and settlement account B. A new settlement account C is added as the first repayment account, the settlement account A becomes the second repayment account, settlement account B, the third repayment account.

When the user has updated the settlement activity with the effective date as current date, changed the order of payin accounts as C first, then A and set the Update Pending Retry field to Yes, the following occurs:

• The system creates new pending request on settlement account C as priority 1, by copying all the pending request retry characteristics of settlement account A.
• The system creates new pending request on settlement account A as priority 2, by copying all the pending request retry characteristics of settlement account B.
• Rc Status on account B is updated as TERMINATED with reason: Pay In Account Removed

Illustration

An existing loan is in Delinquent status with outstanding bills in RC. The user updates the settlement activity with a change in account number and sets Update Pending Retry as Yes.

The RC.DETAIL before change in account number is shown below.

The RC.DETAIL after change in account number is shown below.

• Rc Status is updated as TERMINATED.
• RC.DETAIL is updated for the older bill for the changed account number and the bill is partially settled, based on the funds availability.

Read Retry Processing from Multiple Accounts for more information.

Illustration

Sample configuration of Transaction Cycler for Mortgages and Long term deposits is shown below.

Setup up illustration using RC

The Payin Rc Condition and Payin Rc Type fields are 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 the 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 conditions for this type of transaction.

These records will be released by Temenos, but could be modified by the user

RC.CONDITION

Different records in RC.CONDITION are created with Retry Frequency (Retry Fqu) and Transaction Type (Txn Type), which can be attached under the Settlement product conditions.

If Write To History is set as Yes, and if the dues or funding is settled fully, then the record moves from RC.DETAIL to RC.DETAIL.HIST

Some of the conditions (RC.CONDITION) configured are shown here.

RC.CONDITION for daily frequency is shown below.

RC.CONDITION for business day is shown below.

RC.CONDITION for deposit products with frequency set as Business Day with Retry Attempts is shown below.

RC.CONDITION is set for deposits product with frequency as business day and Retry period is set as 7 days.

RC.CONDITION set for deposits with frequency as Business Day is shown below.

RC.CONDITION for deposits with Daily frequency is shown below.

RC.CONDITION for deposits with Daily frequency and Retry Attempts is set as 7

RC.CONDITION for deposits is set as Daily frequency, and Retry Period as 7 Days.

RC.CONDITIONS is set for deposits with Retry Frequency as Fortnightly.

RC.CONDITIONS is set for deposits with Retry Frequency as Monthly

RC.CONDITIONS is set for Retry Frequency as Fortnightly

RC.CAPTURE

The table is used to define accounting entries which need to be captured and stored for recycling.

The RC.CAPTURE table is used configure conditions or rules based on which a transaction can be captured by the central accounting engine, that is, based on EB SYSTEM ID.

RC.PRIORITY

This table contains the rules regarding the types of transaction that take priority where there is more than one outstanding transaction against a settlement account

RC.PRIORITY is created with the product groups included to set the prioritisation level.

RC.CONTRACT.PRIORITY

This table contains the rules regarding the types of transactions that take priority where there is more than one outstanding transaction against a settlement account.

RC.CONTRACT.PRIORITY record is 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 the types of transactions that take priority where there is more than one outstanding transaction against a settlement account.

Product level priority is set using the RC.PRODUCT.PRIORITY for the Deposits and Mortgages Product Group. Records created in RC.CONTRACT.PRIORITY are shown below.

Settlement Condition

RC.CONDITION and RC.TYPE are attached under the Settlement Product Conditions at product level.

Deposit Funding

The deposit arrangement is created with PAYIN and PAYOUT account as 65277 which has no balance and the commitment amount for deposit is given as 40000.

In RC.CONDITION, frequency is set as DEPOSITS.DAILY by default in the Settlement Product condition.

As the account has no balance, the deposit account is not funded.

The bill gets generated with status as Expected, as deposit funding is not made.

The user has to check for the RC.DETAIL for the account given in Settlement conditions. The Settle Status field is updated as Pending and Retry Start Date as 29 Mar 2013.

Loan Auto Disbursement

The loan arrangement has the same account for Payout (65277) and different account in Payin (65269) settlement conditions, and the commitment amount is input as 450,000 USD.

RC.CONDITION is set as DAILY by default (Retry frequency) from the settlement product conditions.

After authorisation, auto-disbursement is made to the account 65277 mentioned in the Payout Account, but the due charges are not settled as the Payin account has nil balance.

The bill gets generated for NEWARRFEE Activity charges and with status as Due, as Payin account has nil balance.

RC.DETAIL

RC.DETAIL records are found for account specified in PAYIN balances 65269. Since the charges are not settled, an RC.DETAIL is created.

Loan Manual Disbursement

Another loan is created without auto-disbursement with PAYIN account, with account 65323 as settlement account. This account also has zero balance.

The commitment amount is 40,000. RC.CONDITION has DAILY set by default (Retry Frequency) from the Settlement product condition.

Payin account 65323 has no balances.  Therefore, Due charge is created

The bill gets generated for Due Charges with status as Due.

Through FT, a disbursement for the arrangement is done.

RC.DETAIL

Check for RC DETAIL record for the new account. RC.DETAIL is created as the charges are due.

Transaction Cycler in COB process

Before COB, note the balances 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 Write To History is set as Yes.

Deposit Funding

The RC record is moved to history now.

The user can view the Deposit arrangement after the bill is settled.

The bill status is updated as settled.

Deposit is funded and the expected bill is settled by the system, by Transaction Cycler.

Loan Auto Disbursement

The outstanding RC record is in history now.

View the arrangement after the settlement is made. The bills statuses are settled.

Loan with Manual Disbursement

The RC record is moved to history now.

The user can view the arrangement after the settlement is made.

The bill status is updated as Settled.

Charge bill is settled by system through Transaction Cycler.

Activity Charges bill gets settled in Lending Arrangement if auto-disbursement is set and the same account is given in both settlement conditions.

During the capitalisation process to settle the interest or charges to credit an account, if there is a payment rejection, the same can be retried using the Transaction Cycler.

It is possible to configure the payment rejection to accounts that are dormant or has posting restrictions. In such cases, the user can further have transaction cycler for those transactions to be retried.

In Settlement condition the RC Condition and RC Type fields are there to choose the RC settings.

The rule to credit the account is indicated through PAYOUT.AC.CR.RULE

This rule can be setup using AA.SETTLEMENT.TYPE records.

Based on the configuration in AA.SETTLEMENT.TYPE and the defined RC.TYPE and RC.CONDITION in settlement conditions, the system periodically retries to post the debit (payin) or credit (payout) entry.

User-defined Rule Based Settlement Processing – AA.SETTLEMENT.TYPE

A user-defined rule routine can be defined in Settlement Type, which can be triggered during settlement and linked for Transaction Recycling. This can be attached to payin and/or payout condition to have an advanced rule in addition to Full, Partial or None.

Debit Rule

The field decides the manner in which system should utilise the funds available in Payin Account during settlement process with options as Full, Partial and None explained earlier.

User Rule Routine

User defined routine is attached here.

Before processing the Auto settlement or RC, this API is called and checked whether exceptions are raised.

1. If any exception raised, then further settlement processing by Auto Settlement or RC is skipped.

2. Only when no exceptions are thrown, further settlement processing continues either by RC or Auto Settlement.

The routine must contain the following arguments.

Input Arguments

• CallType: Indicates the calling application. Either RC or SETTLEMENT.
• CallApplicationRecord: Contains the calling application Record that is, if the call type is RC then the RC.DETAIL record or Settlement then settlement array of corresponding multi-value set is passed.
• SettlementMethod: Indicates the settlement request - DEBIT (for Payin) or CREDIT (Payout).
• ArrangementAccount: Arrangement Account Reference.
• SettlementAccount: Settlement Account Reference.
• SettlementAmount: Settlement Amount to be collected from the settlement account.
• SettlementType: Reference of AA.SETTLEMENT.TYPE

Output Arguments

Exceptions: Valid Temenos Transact error IDs for any exceptions raised. Multiple error IDs are separated by #

Given below is a settlement type that is a user rule routine which evaluates the dormancy status of the arrangement. This routine blocks the settlement from or to a dormant account.

Illustration

Given below is a sample RC.CONDITION setup for handling Payout settlements.

Interest Credit to Account with Posting Restrictions

The deposit has Daily Interest Payout and a Settlement account which has a posting restriction. The arrangement start date is 19^th April 2019.

Settlement Account Overview with posting restriction from 19^th to 23^rd April 2019 is shown below.

When a COB is triggered on 22^nd April, note that the Interest Payout gets successfully settled until 23^rd April, once the posting restrict is lifted from the account during Start of Day.

On 23^rd April, the credits are posted on the Settlement account.

RC.DETAIL.HIST holds the information on the retry details and settlement status when each Interest Payout Bill is triggered by the system.

Observe in RC.DETAIL.HIST entry, the settlement status and retry history is stored. Until the bill gets settled the RC record is held in RC.DETAIL table. Upon successful settlement it moves to RC.DETAIL.HIST.

AA BILL DETAILS record is updated as below.

Funding of Deposit from Dormant Account

A deposit is linked to a Pay In settlement account which is dormant.

Recycler Condition retrying to deposit funding on a daily basis is shown below.

Settlement Type record for dormancy evaluation is created.

A deposit is created with Payin account which is dormant.

RC.DETAIL record for with Pending status since deposit funding is on hold due to a settlement account which is dormant.

Settlement Instructions is shown below.

The Dormancy status of the Settlement is changed to Active through a Manual Dormancy reset activity. This is achieved by triggering a funding on the account for USD 50000. The account which was dormant on 17^th April becomes active on 18^th April after the Dormancy Reset Activity.

Once the account becomes active, during the subsequent retry cycle (COB) the deposit is funded with USD 10000 and the account balance reduces to USD 40000 on 19^th April.

Fully Funded Deposit is shown below.

Bill Details screen is as follows.

RC Details in History after Settlement

TheBeneficiary field is a link to the core BENEFICIARY table and is used to define the ultimate beneficiary of the funds. Along with values from the PAYMENT.ORDER.PRODUCT record the BENEFICIARY record is mapped to the PAYMENT ORDER application and to FUNDS.TRANSFER (FT) or TPH.

A Temenos Transact account which is to be credited, can be defined in the beneficiary record. The beneficiary can be customer or bank defined

It is an optional field with the below features:

• It is mutually exclusive with Account
• It is used in conjunction with Pref Product
• It drills down to the BENEFICIARY table

• The BENEFICIARY table captures and maintains customers’ most frequent payee details.
• A Payee once setup can be used while initiating payments, setting up a payment order, or used in settlement conditions for loan and deposit to indicate where the disbursement or deposit payment should be made.
• User can be cautioned when changing an account number in the payee instruction if this is used in any active contracts, that is, settlement conditions.
• To control this, set the option Validate Beneficiary Link as Yes in DE.BIC.PARAMETER. Once initiated, system uses the BENEFICIARY.LINKS record to generate a warning message during the account closure process or if a beneficiary record is changed, it produces an override message.

For example as shown below, a Long Term Deposit Product can be defined in this case for which the Settlement Product Condition is attached and defaulted with a preferred Payment order products  as INTFUND and DOMESTIC.

As per product configuration, the above shown DEPOSIT.LONG Product Condition can be attached to the Deposit Product 

Example Deposit Funding

In the following worked example, it is shown that a Payment order can be generated to fund the deposit arrangement. The same configuration and set-up can be used for other purposes like

• Funding a monthly deposit amount (recurring deposit)

• Deposit maturity – that is, pay interest to one beneficiary and principal amount to another.

• Regularly make a payment from a deposit on a scheduled basis

As shown below all the required details are captured in the input screen.

For settlement and funding, the following BENEFICIARY record has been defined.

For the Maturity deposit the following BENEFICIARY record has been defined and captured.

The deposit needs to be authorised in the usual manner.

After authorisation of the Long Term Deposit arrangement, click on the Payment Order tab under the Additional Details banner.

On clicking this, the Payment order details are shown as below,

For the Long Term Deposit account no 83558-

The following screen shot shows the details of P1161130LV5FDN88 payment order, which also consists of Payment System ID which is nothing but an  FT ID – FT 16113GCRZN

Following screenshot shows the Funds Transfer details

After running necessary OFS service (BNK/OFS.MESSAGE.SERVICE) which processes the payment orders, the status in the Overview screen for the Deposit Account changes from Not Funded to Current.

Payment Order Settlement On Value Date

Deposit Funding

A Fixed Term deposit for the principal balance of USD 10,000 is due to mature on the 19^th April and paid out via a Payment Order.

The   settlement has already been established with the required beneficiary and payment order product details configured.

Loan Repayment using TPH

A vehicle loan for USD100,000 with a constant repayment frequency for every 2days is created.

After 2 days of COB, the bill gets generated for 548.70 USD on 26^th April 2019.

Payment Order generated for Repayment amount of 548.70 USD on 26^th April 2019.

Run the BNK/PAYMENT.STPFLOW.HEAVY Service and check in the ENQ PAY.PEN.PROCESS enquiry whether the payment is successful or not.

Settlement When Payment Order Fails

A Fixed Term deposit for the principal balance of USD 10,000 is due to mature on the 19^th April and paid out via a Payment Order.

The settlement has already been established with the required beneficiary and payment order product details configured.

Payment Order generated

Contract is matured and ready to get settled to the beneficiary.

But due to incorrect beneficiary information and the bill is not settled. A manual Payment Order has to be created to settle the bill.

Confirmation is received that payment has been made – Pay balances are allocated.

1. Debit the PAYACCOUNT balance for USD10,000.00
2. Debit the PAYDEPOSITINT balance for USD0.03

The bill is marked as Settled.

Split Payment Order For Multiple Beneficiary

A Fixed Term deposit is due to mature on the 19^t April with principal and interest being paid out via a Payment Order. The principal balance is USD10,000.00.

Meanwhile the customer sends an instruction for the deposit’s maturity and asks for 60% to be paid to one beneficiary and the remainder to be paid to a second beneficiary.

The settlement had already been established but the instructions are amended based on the communication received.

The Product’s PAYOUT.RULES are configured to settle in the following AA Property order with a DEPOSITINT (interest) first then the ACCOUNT (Balance) sequence.

The bill is marked as Settled.

A Long Term Deposit arrangement with Payment Method as PAY for DEPOSITINT Property is created and funded with a Deposit Interst Payout scheduled for every two days.

ISSUE.OREDER Activity gets generated two days prior to the actual bill date based on the setup in the CURRENCY and PAYMENT.OREDER.PRODUCT applications.

DEPOSITS-SUSP.PAYMENT-ARRANGENT Activity gets triggered and the Interest amount parked in the new balance type SUSPPAYMENT balance type.

• 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.
• 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 becomes NEW and after authorisation, the same should be changed to AVAILABLE.
• The mandate created through DD.DDI should be updated in the Mandate Ref field in the Settlement Property Condition of the arrangement using LENDING-UPDATE-SETTLEMENT Activity. The Payment Type field can hold any of the payment types defined in Payment Schedule. The Settle Method field should be DD.
• During bill issuance, records in DD.ITEM are created for every payment type defined in Settlement Property with the contract reference as the AA.ARRANGEMENT.ACTIVITY ID of the issue-bill Activity.

• The Issue Bill Activity triggers creation of DD.ITEM records for the payment types that are mentioned in the Settlement Property.
• The status of the DD.DDI record is 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. After the DD processing on the payment date of the bill, the DD.ITEM record updates the status to CLAIMED.ITEM.

Account to be used as counter booking account when the current arrangement is off-balance and counter bookings should therefore not go to PL account.

In a normal interest or charge processing, the system debits or credits the arrangement and credits or debits the PL. In the case of off-balance sheet memo accounts, even the accrual of interest does not hit the PL. During make-due or pay or capitalise, the system debits or credits the memo account but needs another account to book the other side of the transaction. This field is used for that purpose.

It is mandatory for off-balance accounts which have any setup to process interest or charges.

This field is used for counter booking. For example, in the case of memo accrual of credit interest, the memo account is credited with the interest accrued and the counter booking account is debited. In such cases, the Activity specified in this field is used to run on the Account.

This field is mandatory for off-balance accounts when the counter booking account is specified.

It is also used for counter booking. For example, in the case of memo accrual of debit interest, the memo account is debited with the interest accrued and the counter booking account is credited. In such cases, the Activity specified in this field is used to run on the Account.

This field is mandatory for off-balance accounts when the counter booking account is specified.

• ACCOUNT-SETTLE.SUSP-DUE-SETTLEMENT.ACCOUNT

  Accounting to debit CUR balance of Settlement account.

• ACCOUNT-SETTLE.SUSP-PAY-SETTLEMENT.ACCOUNT

  Accounting to credit CUR balance of Settlement account.

• ACCOUNT-SETTLE.SUSP-DUE-COUNTER.BOOK.ACCOUNT

  Accounting to debit CUR balance of counter booking account

• ACCOUNT-SETTLE.SUSP-PAY-COUNTER.BOOK.ACCOUNT

  Accounting to credit CUR balance of counter booking account

• ACCOUNT-SETTLE.SUSP-DUE-CURRENT.ACCOUNT

  Accounting to debit CUR balance of schedule account during capitalisation of off balance accounts.

• ACCOUNT-SETTLE.SUSP-PAY-CURRENT.ACCOUNT

  Accounting to credit CUR balance of schedule account during capitalisation of off balance accounts.

Consider a loan with the following bills scheduled to be made due on day 22 of every month:

• Instalment amount of USD 5648.69
• Scheduled charge of USD 999
• Periodic charge that collects all the deferred charges for the month
• Regular overpayment of USD 50

The Combine Bills field is set as Yes in the payment schedule condition.

The settlement instructions are defined to automatically settle the due bills using the settlement account 101214. All the payment types configured in the settlement instructions have the same Payin Settle Activity and the Payin Account Settlement field is set to Combined.

Since the Payin Account Settlement field is set to Combined, on the bill due date 22 April, the amounts of the bills that satisfy the below criteria are combined and settled using a single settlement entry:

• Combine Bills in the payment schedule condition is set as Yes.
• Bills have the same payment date (22 April).
• Bills are configured to be settled using the same Temenos Transact account (101214).
• Same Settle Activity LENDING-APPLYPAYMENT-PR.REPAYMENT is defined for all the bills.

The corresponding due balances are settled as seen in the below screenshot.

The AA.ACTIVITY.HISTORY table for the arrangement shows that the bills are settled using a single settlement entry for the combined amount. The payment rule condition is defined to credit USD 50, the regular overpayment amount to the UNC<ACCOUNT> balance. That is, the Remainder Activity field in the payment rule condition is set to LENDING-CREDIT-ARRANGEMENT.

Consider a loan with the following bills scheduled to be made-due on the 22nd of every month:

• Instalment amount of USD 5648.69
• Scheduled charge of USD 999
• Periodic charge that collects all the deferred charges for the month
• Regular overpayment of USD 50

The Combine Bills field is set as Yes in the payment schedule condition.

The settlement instructions are defined to settle the Due bills automatically using the settlement account 101346. All the payment types configured in the settlement instructions have the same Payin Settle Activity and the Payin Account Settlement field is set to blank.

Since the Payin Account Settlement field is left blank, on the bill due date (22 April), the functionality to combine the bill amounts and generate a single settlement is not applicable. The system continues to generate the settlement entries based on whether the settlement instructions are multi-valued or sub-valued.

In this case, the system settles the annuity, scheduled charge and overpayment amount using a single settlement entry. The periodic charge is settled using a separate settlement entry.

The corresponding due balances are settled as seen in the below screenshot.

The AA.ACTIVITY.HISTORY table for the arrangement shows that the system settles the bills using multiple settlement entries. The payment rule condition is defined to credit the regular overpayment amount of USD 50 to the UNC<ACCOUNT> balance. That is, the Remainder Activity in the payment rule condition is set to LENDING-CREDIT-ARRANGEMENT).