Arrangements COB Processing

Batches and Jobs

Scheduled Activities

Arrangement activities are processed using the AA.ARRANGEMENT.ACTIVITY application and these can be initiated in a number of ways:

• User initiated request
• Non AA-transaction initiated – for example when crediting or debiting an arrangement account from an existing application.
• As a scheduled process – the activity should be processes automatically according to a some schedule defined for the product or arrangement

Some activities may be initiated in more than one way. The valid initiation types are defined in the AA.ACTIVITY.CLASS definition which is released by TEMENOS. The definition is contained in the ACTIVITY.TYPE field. The initiation method of activities is pre-defined and cannot be amended.

Scheduled activities are processed as part of the Close of Business (COB) and specific BATCH records are released with the relevant jobs required to perform the contract processing.

Sequence of Activities in Batch Processes

Several activities may be scheduled to be processed for an arrangement on the same date, the sequence the activities are performed in is important and this is defined as part of the AA.ACTIVITY.CLASS definition.

Each BATCH process that should perform the scheduled activity is specified in the AA.ACTIVITY.CLASS record together with a numeric sequence which is used to determine the order that the activities are executed for an arrangement.

The definition of the batch and sequence are pre-defined and cannot be amended.

Arrangement Contract Scheduled Activities

Arrangement contracts for products that have scheduled activities maintains a list of scheduled activities to be performed for that arrangement together with the next scheduled event date and the last time it was performed.

These details are maintained in AA.SCHEDULED.ACTIVITY. The details are updated as part of the activity processing for arrangement property maintenance and the scheduled activity itself. For example, the creation of a new loan contract updates the next scheduled MAKEDUE activity when the PAYMENT.SCHEDULE is initially defined or subsequently modified. The MAKEDUE activity itself cycles forward to the next due date and ensure that AA.SCHEDULED.ACTIVITY reflects this.

 

Accrual Frequency

Activities such as Accrual and Amortisation perform internal accounting processing (that is, the booking of P&L) rather than actions that relate to the customer of the contract. The frequency for performing these activities does not form part of the product definition and is instead controlled by a central accrual frequency definition in AA.ACCRUAL.FREQUENCY.

A single definition exists for each financial company that allows the frequency to be defined at the following levels for properties that can be accrued:

1. For a specific property of a specific product.
2. For a specific property in any product.
3. For any property.

For each of theses combinations different frequencies can be defined for local and foreign currency contracts.

The following frequency options are allowed for accrual: 

• DAILY – The accrual processing takes place for each CALENDAR day, that is, on a Friday COB for a normal weekend, there are three accrual activities processed for a contract.
• BSNSS – The accrual processing takes place for each business day, that is, on a Friday COB for a normal weekend, there is one accrual activity for a contract that covers the period Friday – Sunday inclusive.
• Mnndd – The accrual is performed every nn months on the dd day of the month. If 31 is defined as the day, this indicates that processing must take place on the last day of the month.
• Null – No accrual is to be processed on scheduled basis at all.

Only properties that belong the INTEREST or CHARGE Property Classes can be defined in AA.ACCRUAL.FREQUENCY. 

It is also possible to reverse the earlier accruals/amortisation and rebook them daily by setting up ACCR.REV.PARAM. 

For more details, refer to the REPORTING user guide.

Example

In the above example, the following frequencies would be applied:

• Product HIGHVALUELOAN.
  • Interest property CURRINT for local currency contracts is accrued monthly on the 15^th of the month.
  • Interest property CURRINT for foreign currency contracts is accrued on a daily basis.
  • Interest property PENALTYINT for local currency contracts is accrued monthly on the 15^th of the month.
  • Interest property PENALTYINT for foreign currency contracts is accrued daily.
• Any product other than HIGHVALUELOAN using PENALTYINT interest property.
  • local currency contracts are accrued monthly on the last day of the month.
  • foreign currency contracts are accrued daily.
• Any other interest property or product.
  • Local currency contracts perform no scheduled accrual.
  • Foreign contracts are accrued quarterly on the last day of the month.

Activities that determine their processing frequency as scheduled tasks are defined in the AA.ACTIVITY.CLASS record. The field ACTIVITY.TYPE contains ACCRUAL to indicate this. This is pre-determined and cannot be modified.

Processing the Activity

When a scheduled activity is processed, an AA.ARRANGEMENT.ACTIVITY transaction gets performed the transaction request contains the arrangement number, required activity and effective date for the request. The effective is the actual date that the activity should be processed on.

The activity request is performed by the TSA service running the process through OFS. Scheduled activities are processed without the need to separate authorisation, in the case of processing error or exception the activity request leaves in HLD status and can be completed manually. The detail of error and exception (for example, override) processing depends on the operation of the specific activity.

For frequently repeated activities such as accrual, the same AA.ARRANGEMENT.ACTIVITY transaction is used for each scheduled event. For all other scheduled activities, separate AA.ARRANGEMENT.ACTIVITY transactions gets generated.

It is possible to reverse scheduled activity requests after the scheduled activity has taken place (subject to any restrictions that a specific activity may have).

Transaction Management

For each arrangement and processing date, the system processes all scheduled activities together. Activities are performed in the correct sequence and forms a single database transaction, Any error or failure of an activity means that all activities for that arrangement and processing date are not going to be processed.

Batch – AA.EOD.PROCESS

This performs arrangement processing in the End of Day section of the close of business. The Batch is defined for each Financial company in a multi-company implementation and runs in the system wide section of the close of business.

The following processes are run as part of this batch:

• Processing of Payments in and out of arrangement accounts generated as part of the close of business.
• Processing of scheduled activities for the products. 

Batch – AA.SOD.PROCESS

This performs arrangement processing in the Start of Day section of the close of business. The Batch is defined for each Financial company in a multi-company implementation and runs in the start of day section of the close of business.

The following processes are run as part of this batch:

• Processing of Payments in and out of arrangement accounts generated as part of the close of business.
• Processing of scheduled activities for the products.

Job - AA.SERVICE.PROCESS

Technical Details

The selection of contracts is driven from the internal table AA.NEXT.ACTIVITY. This contains one record for each arrangement contract with the contract number and next scheduled activity date of any type, it is maintained with the AA.SCHEDULED.ACTIVITY table. A filter routine is used to ensure that only arrangements with an activity due for that process date, or with a possible accrual frequency are added to the JOB.LIST for processing.

Job - AA.COB.PAY.IN.OUT

Description

This job submits and completes processing of AA.ARRANGEMENT.ACTIVITY requests generated by non-AA transactions during close of business. During close of business processing, the payment transactions generates AA.ARRANGEMENT.ACTIVITY requests in HLD status.

The processing checks all AA.ARRANGEMENT.ACTIVITY records in HLD status that are for activities relating to payment types. Payment Type activities are identified by the definition of ACCOUNTING in the ACTIVITY.TYPE of the underlying ACTIVITY.CLASS.

The requests are submitted to OFS in zero authoriser mode. In the case of error or override, the transaction remains in HLD status and must be processed manually.

Technical Details

The AA.ARRANGEMENT.ACTIVITY $NAU table is selected.

The record processing determines that:

• The record status is HLD
• The activity is a payment type

If both cases are true, then the activity starts processing.