Sei sulla pagina 1di 24

TEMENOS T24 DIRECT DEBIT

User Guide

TEMENOS T24 DIRECT DEBIT User Guide Information in this document is subject to change without notice.

Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Table of Contents Introduction

3

Direct Debit in T24

4

Direct Debits (under Retail Admin Menu-DT)

5

Events

5

Reason Codes

6

Codes

7

Transaction Codes

8

Outward Format

8

Inward Format

10

Parameter (DD.PARAMETER)

11

Workflow for Outward Claims

12

Direct Debit (under Retail User Menu)

14

Register Direct Debit Instruction

14

Link to MG Application

14

Standalone processing

16

Stand Alone Direct Debit Instruction

16

Collecting Payments

18

Claim File Generation

19

Generate Outward DD Online

19

Return & Resubmission

20

Process return of Outward Claim

20

Claim Accounting

21

Holiday Processing

21

Enquires

22

List MG Link Details

22

List DD Items

22

Claim View

23

Incoming Claims

24

Workflow for Inward Claims

24

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Introduction

Direct Debit (DD) is the simplest way for an organization to collect regular or occasional payments from their Customers account with another bank. It saves time, reduces the cost of collection and puts cleared funds directly into their bank account.

A Direct Debit is an instruction from a customer to a Bank or Building Society authorizing the organization to collect varying amounts from the Customer’s Bank Account.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Direct Debit in T24

The above business requirement can be achieved in T24 through the DIRECT.DEBIT (DD) module which supports Mandate handling, Creation of Claim, generation of Claim file, Claim Accounting, Return and Resubmission of Claims for Outward claims.

Recording of rejection and Item creation for rejection and definition of file format is supported for the Inward claims from DD module and local accounting interface can be used for raising Accounting entries related to above.

The Direct Debit (DD) module is designed to interface with existing T24 applications via core Accounting System. Currently the MG.MORTGAGE application has the link to DD module and claims can be generated automatically based on MORTGAGE schedules for payment Interest Amount, Principal Amount, Commission and Charges. Also DD claims can be generated manually (without linking to any T24 application) based on frequency or one time, through the DD.DDI application for standalone processing.

To use the direct debit module, the DD –DIRECT DEBIT product has to be installed in the SPF and COMPANY applications.

The following menus are available in the Model Bank which facilitate the Direct Debit functionality:

Model Bank which facilitate the Direct Debit functionality: Figure – 1 Direct Debit Retail menu Figure

Figure – 1 Direct Debit Retail menu

Debit functionality: Figure – 1 Direct Debit Retail menu Figure – 2 Direct Debit Retail Admin

Figure – 2 Direct Debit Retail Admin menu

The functions listed in the second menu are essentially the main/high level parameter files within Model Bank and will be set up during the implementation. As such the end users would not be required to input or modify these on a daily basis.

These functions are detailed in the following section of this manual.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Direct Debits (under Retail Admin Menu-DT)

Events

List of events as applicable is given in this application as an ID along with its description. The events defined here are used in Direct Debit Registration (DD.DDI) application and is also used for updating the live file DD.ITEM. These events control the generation of accounting entries related to Claim, Reversal and Resubmission as well as population of reason codes for claim file.

The following is the description of an event called ‘ACTIVE’

following is the description of an event called ‘ACTIVE’ Figure 1 - DD.EVENTS with description Following

Figure 1 - DD.EVENTS with description

Following are the list of events that are currently recognized by the DD applications.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit Reason Codes Table 1 - List of Allowed DD.EVENTS The file

Reason Codes

Table 1 - List of Allowed DD.EVENTS

The file sent for claiming Direct Debit (DD) amount should contain codes as applicable for a clearing system to indicate whether it is a first claim (i.e. Claim presentation after DDI lodgments) or subsequent claim or return of an item etc. These reason codes related to Direct Debit for a clearing system are defined here along with the description, which is displayed as enrichment when these codes are referred to in other DD applications. The same are set up in the application DD.REASON.CODES

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit Figure 2 - Example for DD.REASON.CODES Codes A code that is

Figure 2 - Example for DD.REASON.CODES

Codes

A

code that is defined in the above (DD.REASON.CODES) application is linked to an Event as defined

in

DD.EVENTS through the application - DD.CODES and the appropriate reason code is defaulted in

DD.ITEM record-based on respective events.

is defaulted in DD.ITEM record-based on respective events. Figure 3 - Linking Events & Reason Codes

Figure 3 - Linking Events & Reason Codes in DD.CODE

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Transaction Codes

A transaction code that has to be used while generating accounting entries has to be specified in the application DD/TXN.CODES for each event, such as, NEWCLAIM, RETRUN, RESUBMIT and REJECT. A transaction code defined here is applicable for all clearing systems.

code defined here is applicable for all clearing systems. Figure 4 - DD.TXN.CODES with Transaction codes.

Figure 4 - DD.TXN.CODES with Transaction codes.

Outward Format

Each clearing system has their prescribed file format for outward claim submission and return. These formats are defined in DD.OUT.FORMAT, which has three sections, namely, Header, Data and Footer and it is attached to the relevant DD.PARAMETER for Claim file generation. In the Header, Data and Footer section, details can be specified either as a static information related to file or can be linked to other applications using DD.ITEM information to get the clearing reference, Bank sort code, value date and amount etc from the DD.ITEM application.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit Direct Debit Page 9 of 24 July 2003

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit Inward Format Outward Claim file, which is generated through above process

Inward Format

Outward Claim file, which is generated through above process has to be submitted to Customer Bank through clearing agency. Customer Bank on receipt of the file has to process the incoming file by deconstructing the details and pass accounting Entries. This inward processing has to be handled using local interface, which can use the DD.IN.FORMAT details to deconstruct the detail and map the same to DD.ITEM. Local interface routine can be written to generate incoming claim accounting entries.

In DD.IN.FORMAT application we can specify the DD.ITEM field name to which incoming details to be mapped along with the position from which the information to be extracted from incoming file can be specified along with delimiter or the number of characters. Also routine can be attached to map the details to DD.ITEM.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Parameter (DD.PARAMETER)

This is a high level parameter file and contains the details related to Direct Debit processing such as Clearing Account category and Suspense account category which are to be used for Claim accounting, Value date before the Claim to be submitted/Resubmitted, Claim file name and location (Both Inward/Outward), No. of days after which file to be moved to History and history file location, Holiday processing, whether Standalone DD is allowed or not etc.

The id can accept a 4-digit numeric and this id has to be given in DD.DDI to link the parameter setting to the individual Claim.

to link the parameter setting to the individual Claim. Figure 5 - DD.PARAMETER Direct Debit Page

Figure 5 - DD.PARAMETER

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Workflow for Outward Claims

Model Bank – Direct Debit Workflow for Outward Claims Figure 6 - Workflow for Outward DD

Figure 6 - Workflow for Outward DD Claims

To begin with, the Customer completes the direct debit instruction (DDI) form and hand it over to the organization (Direct Debit Originator) through which the DD is to be collected.

The Direct Debit Instruction requires following details:

Name and address of Bank or Building society, which will be collecting the DD amount.

Sort code of the Customer bank, which is to be debited.

Customer Bank Account number

Customer Bank Account holder details.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

The completed direct debit instruction (and registered in the system) has to be forwarded by the Direct Debit Originator to the Customer’s Bank where the debit account is maintained. Should the details be incorrect, the Customer’s Bank can reject the DDI.

The actual processing of the Direct Debit are made available through the functions provided in the first menu shown in the beginning of the document viz. Direct Debit under Retail User Menu :

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Direct Debit (under Retail User Menu)

Register Direct Debit Instruction

To register a Direct Debit Instruction received from a Customer on Model Bank, you need to access the following menu:

Retail User Menu>Direct Debit>Register Direct Debit Instruction

Completed Direct Debit Instruction for a Customer’s account:

Direct Debit Instruction for a Customer’s account: Figure 7 - Direct Debit instru ction details for

Figure 7 - Direct Debit instruction details for Account 22497

Link to MG Application

Retail User Menu>Direct Debit>Link to MG Application

To trigger automatic claim processing from MG.MORTGAGE based on MG schedules, choose the REPAY METHOD as “DD” and link the DD.DDI (Mandate), which has the status as “ADVISED”, ”AVAILABLE” or “ACTIVE” in the field DD.MANDATE.REF of the MG application.

The DD.DDI record can be linked to MG only when the MORTGAGE.ACCOUNT matches with the DD.DDI ID account. Once the DD.DDI record is linked to MG and after the related DD.ITEM is included in the claim file during the COB process, the status of DD.DDI automatically changes to “ACTIVE” to indicate that the mandate is in use.

The DD.ITEM record is created automatically with amount, value date and reference number for each forward entry raised from MG for the MORTAGE.ACCOUNT. The DD.ITEM is updated with status as “NEW.ITEM” along with the reason code as applicable for that event

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit Figure 8 - DD Mandate linked to MG application In the

Figure 8 - DD Mandate linked to MG application

In the above example an MG contract is created which has an equated monthly repayment of USD 857.45 (i.e. Interest Repayment of USD 42.07 + Principal repayment USD 815.38) every month

from 26 th November 2005. Since the DD processing is enabled by linking the Mandate

starting

“22497.1” to the MG Contract, for each forward entry created for the MORTGAGE ACCOUNT, the system creates a DD.ITEM record with the respective details and with the status “NEW.ITEM”.

the res pective details and with the status “NEW.ITEM”. Figure 9 - Forward entries details Direct

Figure 9 - Forward entries details

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit Figure 10 - DD.ITEM is created for the Principal Repayment. In

Figure 10 - DD.ITEM is created for the Principal Repayment.

In case the Direct Debit Instruction (DD.DDI) is submitted for the first time after DDI lodgments for claim processing (i.e. DD.DDI old status is not “ACTIVE”) then during actual claim file generation the DD.ITEM status is updated as “FIRST.CLAIM” and updated with the appropriate reason code from DD.REASON.CODES.

Whenever the details in an underlying MG contract are changed, then the existing DD.ITEM record is de-linked and the status is updated as “DELETED.ITEM” and a new DD.ITEM is created with the current MG details. These deleted items will not be picked by claim file generation. However in case the claim is sent for the underlying DD.ITEM, (i.e. DD.ITEM already has the status as “CLAIMSENT.ITEM”) then Item cannot be de-linked and an override is raised in the MG application.

Standalone processing

Stand Alone Direct Debit Instruction

Retail User Menu>Direct Debit>Standalone Direct Debit Instruction

To generate claims manually with a user-defined frequency for standalone processing, the same DD.DDI application is used with ALLOW.DD.STD set to ‘Y’ in DD.PARAMETER. The details required in the DD.DDI are to be input (like amount, currency market and required frequency for which claims are to be created) duly ensuring that the STAND.ALONE.DDI field is set to ‘Y’.

On entering the above details in DD.DDI, forward entries are created for the mandate account and the standalone clearing account, which in turns creates DD.ITEM records with the given amount and value date.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

In the below example, on the 4th of every month starting from 4th Nov 2005, USD100.00 has to be claimed and credited to the account 22497. The claim has an end date of 04 th Dec 2005.

22497. The claim has an end date of 04 t h Dec 2005. Figure 11 -

Figure 11 - Mandate created for 22497 as Standalone claim

Based on the above information, forward entries for the immediate claim and DD.ITEM record are created as given below.

claim and DD.ITEM record are created as given below. Figure 12 - Forward entries raised from

Figure 12 - Forward entries raised from DD.STANDALONE

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit Figure 13 - DD.ITEM created based on DD.STANDALONE details When the

Figure 13 - DD.ITEM created based on DD.STANDALONE details

When the standalone frequency detail is changed, then the underlying DD.ITEM is marked as “DELETED” when the claim is not sent. Otherwise an override is generated with information “Item cannot be declined”.

Collecting Payments

Once a DDI is accepted by the Customer’s Bank, the Direct Debit Originator can send the claim. Based on the clearing cycle, a claim has to be submitted in the prescribed file format though the clearing agency to the Customer’s Bank. Each clearing system has a different processing cycle and file format.

For example BACS clearing process has a 3-day cycle as follows:

Day 1: Claim file has to be submitted to BACS for a processing cycle.

Day 2: File sorting and forwarding by BACS to respective banks.

Day 3: All payments are simultaneously debited and credited to the relevant accounts of the member banks of the clearing.

The Direct Debit claim can be returned unpaid by the Customer's Bank along with details of reason for non-payment, and the DD Originator’s account will be debited with the original claim amount within 2 or 3 working days. These un-paid claims can be resubmitted with the same details again for claim processing. A unique transaction code is given by respective clearing agency for each activity related to DD processing to understand whether it is a first claim after DDI lodgments, Direct Debit claims, Returns etc, and these codes have to be used while sending the Claim file.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Claim File Generation

The Direct Debit claim has to be submitted to the Customer’s Bank in the prescribed format as per the clearing day schedule. In the DD module, these claim files can be generated as per the format and number of days before the value date as given in DD.PARAMETER, either as online or during the COB batch process.

To generate the claim file, the number of days as given in the CLAIM.DATE.PRD field in DD.PARAMETER is added with the system date and all the claims from DD.ITEM (with the status as “NEW.ITEM“ and underlying DD.DDI status as “ACTIVE”), with the value date scheduled between the system date up to the claim period date being taken for processing. If the DD.DDI status is “HOLD” or “RETURNED” then these items are skipped during file generation. In case value date is a holiday, then it is based on the CLAIM.HOL.IND set-up in DD.PARAMETER, either included on the previous day file (When set to “Yes”) or the claim is sent on the next day. (Refer to the Holiday processing section)

Generate Outward DD Online

To generate files online DD.GENERATE.FILES has to be verified with an appropriate DD.PARAMETER id. Once the file is generated (either on-line or an COB process), the individual DD.ITEM record status is set to “CLAIM.SENT” and DD.HEADER is updated with the Item details.

The following menu should be accessed to achieve the above-mentioned functionality:

Retail User Menu>Direct Debit>Generate Outward DD Online

Specify the required ID and click on the

Outward DD Online Specify the required ID and click on the button. Direct Debit Page 19

button.

Outward DD Online Specify the required ID and click on the button. Direct Debit Page 19

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

Click on the

Model Bank – Direct Debit Click on the button to generate the file online. Once the

button to generate the file online.

Debit Click on the button to generate the file online. Once the Item is included in

Once the Item is included in the file, it is skipped during the next file generation process. Hence to view a sample file before sending it to the Clearing Agency, set the UPDATE.FILES field as “No” in DD.GENERATE.FILES, then a sample file is generated without updating the Item and Header and this can be viewed from the Hold Control Report.

Return & Resubmission

Process return of Outward Claim

The claim can be returned from the customer’s bank for various reasons. In such case the claim accounting has to be reversed. These returns can be submitted manually or automatically after stipulated period.

The DD.RETURN application is used to register the returns and resubmission. An item that is returned can be updated in DD.RETURN either manually or through an interface process by giving the relevant DD.ITEM.ID along with the reason code for return. An item can be returned only when its status is “CLAIMED.ITEM” (i.e. Claim accounting has been raised on the value date). In case auto resubmission is required then the PERIOD can be specified in field RESUB.DATE.PRD in DD.PARAMETER. Resubmission can also be done using RESUB.VAL.DATE field in DD.RETURN.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit For resubmission an accounting, forward entry is created for the mandate

For resubmission an accounting, forward entry is created for the mandate account and the concerned clearing account with the original DD.ITEM amount along with value date. The value date for the resubmitted forward entry is arrived at based on the resubmit value date as given in DD.RETURN plus the number of days specified for the claim period in DD.PARAMETER. Based on forward entry details a DD.ITEM is created with the required information and then processed like normal claim processing

Claim Accounting

During the Start of Day process, based on the parameter setting, claim accounting is raised by debiting DDI.ACCT.CLASS for Items created through DD.DDI and STD.ACCT.CLASS for items created through standalone processing, crediting the respective mortgage account or DD.Standalone ID account. The status of DD.ITEM is changed to CLAIMED.ITEM. Claim accounting is raised based on the claim file generated for the concerned day with the booking date as the system date and value date as the respective DD.ITEM claim value date. In case scheduled date is a holiday based on the CLAIM.HOL.IND in DD.PARAMETER, entries are raised. (Refer to the Holiday processing section)

Also forward entries raised from DD.DDI for standalone processing and MG are dropped through a generic batch process. During COB MG Batch process, the Mortgage account is debited and credited to the Mortgage due amount (Principal and Interest). Also from MG, new forward entry is created for the next due, which in turn creates a DD.ITEM with the value date and amount.

For a standalone claim, forward entries are created during the Close of business process after cycling based on the frequency. The status of a DD.DDI standalone record is moved to “MATURED” when the termination date as specified in DD.DDI is reached.

Holiday Processing

The scheduled date for the claim file generation or claim value date and cycle frequency date can be a holiday. In such cases whether to process above activities on the previous working day itself or on the next working date can be defined in CLAIM.HOL.IND in DD.PARAMETER.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit

In case of MG, when the Mortgage scheduled repayment date is a holiday, then the repayment entries

are generated on the previous working day by default.

Hence based on the Bank’s requirement, the CLAIM.HOL.IND can be set to either generate the entries before the claim or after the claim date in case of a holiday on the claim date.

Enquires

List MG Link Details

A context enquiry is available in MG.MORTGAGE in field DD.MANDATE.REF, which shows the list of

MG contracts, which are linked to a mandate as specified in the above field. The same can be invoked

by accessing the following menu in the Model Bank:

Retail User Menu>Direct Debit>Enquiries>List MG Link Details

Debit>E nquiries>List MG Link Details Figure 14 – MG.MORTGAGE – DD Mandate link details List

Figure 14 – MG.MORTGAGE – DD Mandate link details

List DD Items

Retail User Menu>Direct Debit>Enquiries>List Items

This enquiry can be used to list the DD.ITEM’s details based on the selection criteria from DD.ITEM fields - Status, Value Date and the Parameter id.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit Figure 15 – DD.ITEM.LIST enquiry with Selection criteria STATUS EQ “NEW.ITEM”

Figure 15 – DD.ITEM.LIST enquiry with Selection criteria STATUS EQ “NEW.ITEM”

Claim View

Retail User Menu>Direct Debit>Enquiries>Claim View

The claim file, which is generated and available in the outward location specified in DD.PARAMETER for a DD.Header detail, can be viewed using the context enquiry available for field RECORD.ID in the DD.HEADER application.

Model Bank – Direct Debit

Model Bank – Direct Debit
Model Bank – Direct Debit
Model Bank – Direct Debit Figure 16 – Context Enquiry for Claim f ile viewing in

Figure 16 – Context Enquiry for Claim file viewing in DD.HEADER application.

Incoming Claims

Incoming claims can be processed with a local Accounting interface set-up through which the required accounting entries can be raised (i.e. Customer account is debited and clearing account is credited). The DD.ITEM.REJECT application is used to reject the incoming claim. In this application the mandate reference, Currency, Amount, Inward account etc can be given, which in turn creates a DD.ITEM with direction as “INWARD”. These details can be sent to the bank that originally sent the claim along with reason for return. However the file generation as per the required files format and rejection accounting has to be handled through the local interface.

Workflow for Inward Claims

*To be handled through Local interface-Refer to inward claim processing.

through Local interface-Refer to inward claim processing. Figure 17 - Workflow for Inward Claims Direct Debit

Figure 17 - Workflow for Inward Claims