Temenos T24 Ac - Expected.Receipts: User Guide

TEMENOS T24
AC.EXPECTED.RECEIPTS
User Guide
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.

Table of Contents
Introduction.............................................................................................................................................. 4
ER.PARAMETER................................................................................................................................. 5
AC.EXPECTED.RECS Work Flow ...................................................................................................... 7
Manual Entry of Expected Funds and Payments............................................................................. 7
Manual Entry of Receipt Fund.......................................................................................................... 8
Auto Creation of Expected Funds from Inward MT210 ....................................................................... 9
Defining Parameters in DE.MESSAGE............................................................................................ 9
Message in AC.EXPECTED.RECS ............................................................................................... 11
Workflow creation of Expected FUNDS from SWIFT Inward......................................................... 12
Automatic Creation of Receipt or Payment Funds Record from FT. ............................................. 16
New Records in AC.EXPECTED.RECS ........................................................................................ 21
Account File Update ....................................................................................................................... 21
Auto Exact Matching Expected with Receipt or Payment .............................................................. 22
Auto Matching of Expected and Receipt or Payment within Tolerance ......................................... 22
Matched Records ........................................................................................................................... 23
Manual Matching................................................................................................................................ 24
Basic METHOD .............................................................................................................................. 24
Using Enquiries – AC.EXP.MATCH and AC.EXP.RECS............................................................... 24
Other useful example Enquires ......................................................................................................... 26
Whether to use the cleared balance or uncleared balance?.......................................................... 26
AC.ENRICHMENT ............................................................................................................................. 30
Batch Processing ............................................................................................................................... 31
AC.EXP.RECS.CLEAR.UNAUTH...................................................................................................... 31
AC.EXP.RECS.EOD .......................................................................................................................... 32
Additional Usage of AC.EXPECTED.RECS.......................................................................................... 33
Correspondent Bank Limit Checking Using AC.EXPECTED.RECS ................................................. 33
Setup Correspondent limit processing ........................................................................................... 34
Step 1: ........................................................................................................................................ 34
Step 2 ......................................................................................................................................... 35
Step 3 ......................................................................................................................................... 36
Step 4 ......................................................................................................................................... 37
Step 5 ......................................................................................................................................... 38
Regular Receipts............................................................................................................................ 44
Amend or use the correct STO.TYPE ........................................................................................ 44
Settings in ER.PARAMETER ..................................................................................................... 45
TEMENOS T24 User Guide

Page 2 of 46
User Routine............................................................................................................................... 45
Example STANDING.ORDER .................................................................................................... 45

Page 3 of 46
Introduction
AC.EXPECTED.RECS records the expected funds or payments in T24 and allows the banks to
determine the projected balances, assisting them to perform their business more efficiently. When the
funds are received or payments made these are recorded and also matched with the expected funds
or payments.
The notifications to receive the funds can be by means of incoming SWIFT MT210, TELEX or PHONE
etc. When a notification is received via SWIFT, MT210 inward message, then the expected receipt
record is created automatically in AC.EXPECTED.RECS file with STATUS WAITING and the
ER.BALANCE on the account file is updated with the expected balance for the value date. Likewise
expected payments may be recorded, either manually or automatically, when an unauthorised FT is
entered and the EP.BALANCE on the ACCOUNT file is updated with the expected balance for the
value date.
When the receipt of funds is recorded in FT, or when a payment is authorised, T24 will automatically
create the RECEIPT or PAYMENT record in AC.EXPECTED.RECS with STATUS WAITING. The
application AC.EXPECTED.RECS will try to match this record with the EXPECTED records in the
system. If a match is found then the STATUS of these records will be changed to MATCHED. If the
RECEIPT record is not matched then the funds are received without notification or the funds are
received before the notification. To cater for this, the system also tries to match the EXPECTED funds
with the RECEIPT or PAYMENT funds, whenever the EXPECTED fund record is created.
On the ACCOUNT record the expected receipt and payment balances for the value date are updated
for all the expected funds in the AC.EXPECTED.RECS for the accounts. The expected funds
amount is added to the appropriate field and the receipt or payment amount is subtracted for the value
date.
Also, the AC.EXPECTED.RECS provides the facility to enter the expected funds records manually.

Page 4 of 46
ER.PARAMETER
The table ER.PARAMETER defines the account/s and or account type (category) to be monitored for
the expected receipts and payments as well as some other parameters. There are only two possible
records in this file SYSTEM and COVER.
SYSTEM is for standard receipts/payments processing
COVER is used to link to FT to set limits on the processing of cover payment message.
Figure 1 ER.PARAMETER

Page 5 of 46
To set which Accounts qualify for selection in AC.EXPECTED.RECS is defined in the ACCOUNT.ID
and/or CATEGORY fields.
You can set the number of days unmatched items and matched items are kept on the system in the
fields AC.OVER.DAYS and AC.RET.DAYS for an account. The system wide and default values
(when not set for individual account) are defined in OVERDUE.DAYS and RETENTION.DAYS.
Fields to be used in the matching process are defined in MATCH.FIELD. The fields ACCOUNT.ID,
CCY.AMOUNT and VALUE.DATE are mandatory since these are crucial to the matching system. In the
TOLERANCE field the user can specify the tolerance to be used in finding the match, the tolerance is
only allowed on the CCY.AMOUNT and the VALUE.DATE fields.
The CCY.AMOUNT tolerance is defined as a percentage of the expected amount. The receipt and
payment records within the limit of the expected records will be matched. If there is more than one
matching record then the first in the list is matched. The system will first attempt for the exact match
before attempting for the tolerance match, but if it is not found the first record found within the
tolerance limits will be.
The VALUE.DATE tolerance is the number of days, before and after the value date, on the matching
record, these are the calendar days. The lower value date is the value date on record minus the
number of working days and the higher limit is the value date plus the number of working days. Once
again the tolerance is used on the record to be matched and the first attempt is for the exact match
and the tolerance is used if the exact match fails.
Also, in matching process the receipt funds are matched with the expected and visa versa.

Page 6 of 46
AC.EXPECTED.RECS Work Flow

After entering the details in the ER.PARAMETER file and authorising it you may then enter details in
AC.EXPECTED.RECS.
Manual Entry of Expected Funds and Payments
The manual entry of FUNDS.TYPE ER is shown below:
Figure 2 Manual Entry of Expected Funds

Page 7 of 46
Manual Entry of Receipt Fund
The manual entry of FUNDS.TYPE receipt is shown below:
Figure 3 Manual Entry of Receipt Funds

Page 8 of 46
Auto Creation of Expected Funds from Inward MT210

Defining Parameters in DE.MESSAGE
T24 can create the AC.EXPECTED.RECS record from an inward MT210 SWIFT message
automatically for the qualifying account(s). For this it is necessary to set up the OFS details, the
VERSION record to use and most importantly the sub-routine in the DE.MESSAGE record for 210.
When the inward delivery service is run the DE.MESSAGE record will be checked and the delivery
system will use the program defined to create the appropriate T24 record or contract, in this case an
AC.EXPECTED.RECS contract.
Figure 4 DE.MESSAGE - MT210 Showing OFS Settings

Page 9 of 46
In OFS.SOURCE field define the ID of the OFS.SOURCE record. This record (TESTOFS) should have
the SOURCE.TYPE set to GLOBUS and may be used by other inward delivery processing.
Figure 5 OFS.SOURCE Details

Page 10 of 46
Message in AC.EXPECTED.RECS
The number of authorisation on AC.EXPECTED.RECS,OFS version is set to one and all the
AC.EXPECTED.RECS records created will be in INAU (no errors), if there are errors then this will be
in IHLD. The other point to note is that the INPUTTER for these records will be …GTUSER_(OFS_ID).
Figure 6 Records Created Via Delivery & OFS
The IHLD messages should be completed manually or deleted if required, and INAU records should
be authorised before the end of business day, if not the system will delete these messages in the
batch. This applies to any records entered manually or created by any other automatic means.

Page 11 of 46
Workflow creation of Expected FUNDS from SWIFT Inward
Inward SWIFT message (in basic form) viewed with ENQUIRY INCOMING.MSG.
Figure 7 Inward SWIFT MT210
The DE.I.HEADER record showing the message has been processed.

Page 12 of 46
Figure 8 OFS Formatted - Inward Record

At this stage the message has been processed by the AC.EXPECTED.RECS deal has not been
completed.

Page 13 of 46
Figure 9 Auto Created AC.EXPECTED.RECS from MT210
The unauthorised AC.EXPECTED.RECS contract which the incoming process created. Once this is
authorised it will update the DE.I.HEADER so a better audit trail is available.

Page 14 of 46
Figure 10 DE.I.HEADER Showing AC.EXPECTED.RECS ID - after Authorisation
The above shows the complete cycle of the notification of expected funds received via INWARD
SWIFT MT210 and the corresponding record created in AC.EXPECTED.RECS.

Page 15 of 46
Automatic Creation of Receipt or Payment Funds Record from FT.

The users can set the system so that the receipt or payment records are created in the
AC.EXPECTED.RECS from the incoming FT. For this purpose the field EXPECTED.RECS should
be set to ‘YES’ in the FT.TXN.TYPE.CONDITION record.
Figure 11 Setting FT.TXN.TYPE.CONDITION to automatic create AC.EXPECTED.RECS
Once this has been defined, qualifying payment FTs will trigger generation of an expected payment
record when unauthorised and authorisation of qualifying FT receipt and payment records will trigger
generation and matching of receipt or payment records in the AC.EXPECTED.RECS file. Please
note that if the EXPECTED.RECS field is not set to ‘YES’ for the FT.TXN.TYPE.CONDITION and it
is not for the qualifying account then a record is not created in AC.EXPECTED.RECS.
If an expected receipt or payment record is created then the ID of this record is displayed in the
information box, and if there was an expected record to which this receipt is automatically matched
then a message to this effect is displayed.

Page 16 of 46
Figure 12 Auto Creation of AC.EXPECTED.RECS record from FT
Here is the FT that was entered (in this case manually) that triggered a match with an expected receipt.
Note that the inward charge of USD15 was applied so the match will be partial as the expected
amount was USD 16,000.00

Page 17 of 46
Figure 13 Auto Creation of AC.EXPECTED.RECS record from FT with information
Figure 14 Auto Created AC.EXPECTED.RECS

Page 18 of 46
Figure 15 FT Input Auto Creation of AC.EXPECTED.RECS

Page 19 of 46
Figure 16 FT Record Showing AC.EXPECTED.RECS Matched record’s ID

Page 20 of 46
Figure 17 Auto Swift and Ft Created - Matched
New Records in AC.EXPECTED.RECS
New expected records created in AC.EXPECTED.RECS will have the STATUS WAITING in the
record.
Account File Update
When the new record in AC.EXPECTED.RECS is authorised the ER.VALUE.DATE, ER.BALANCE

and EP.BALANCE fields are updated on the ACCOUNT file for the ACCOUNT.ID on the
AC.EXPECTED.RECS as shown below, but no account balances are updated. The FUNDS.TYPE
ER will increase the ER.BALANCE and FUNDS.TYPE RECEIPT will decrease it. The FUNDS.TYPE
EP will increase the EP.BALANCE and FUNDS.TYPE PAYMENT will decrease it.

Page 21 of 46
Figure 18 ACCOUNT File Update - ER.BALANCE on ER.VALUE.DATE
Auto Exact Matching Expected with Receipt or Payment
Whenever a new record is authorised in the AC.EXPECTED.RECS the automatic matching

processing kicks in. This will try to match the new record with the existing records of the opposite
FUNDS.TYPE (new RECEIPT/PAYMENT will be matched with the ER/EP or new ER/EP will be
matched with the existing RECEIPT/PAYMENT) and all the MATCH.WITH fields defined in the
ER.PARAMETER.
Auto Matching of Expected and Receipt or Payment within Tolerance
If the exact match is not found and the TOLERANCE is specified in the ER.PARAMETER then the
lower limit and higher limit values are calculated using the base values of the new record and the
TOLERANCE specified. The lower limit and higher limit values are used for TOLERANCE and
MATCH.WITH fields, and exact match for non-tolerance MATCH.WITH fields to find the match from
existing records on the file.
If there is more than one matched record then the first record is selected from the match list.

Page 22 of 46
Matched Records
When two records are matched their STATUS is changed to MATCHED, and the MATCHED.WITH
field will have the corresponding matching records ID.
Figure 19 AC.EXPECTED.RECS Matched information

Page 23 of 46
Manual Matching
Basic METHOD
It is possible to manually match the expected receipt or payment records. The basic method is to go to
the application AC.EXPECTED.RECS or via a version such as AC.EXPECTED.RECS,MATCH
and use input function and select the record to be matched (current STATUS should be WAITING, or
PARTIAL MATCHED), change the STATUS to F (FORCE MANUAL MATCH) and insert or select the
ID of the record to be matched with in MATCH.WITH field. If the records are compatible i.e. the
ACCOUNT.ID and CURRENCY are the same but the FUNDS.TYPE are different then these will be
matched. The record with a lower amount will have STATUS MATCHED i.e. fully matched and the
record with the higher amount will have STATUS PARTIAL MATCHED. The PARTIAL MATCHED
record can be manual matched again with another record.
Using Enquiries – AC.EXP.MATCH and AC.EXP.RECS

Some sample enquiries and versions are provided which can be used for manual matching the
expected receipts and payments. The AC.EXP.MATCH enquiry displays the expected receipt/payment
messages with FUNDS.TYPE EXPECTED and the STATUS WAITING or PARTIAL MATCHED.
The enquiry AC.EXP.RECS displays the records with FUNDS.TYPE of RECEIPT and PAYMENT and
with STATUS of either WAITING or PARTIAL MATCHED.
Using the AC.EXP.MATCH Enquiry the options ‘Details’ and ‘Match expected with the receipts’ will be
shown. Select ‘Match expected with receipts’ option. This will initiate AC.EXPECTED.RECS,
MATCH version.
Figure 20 Manual Match – getting ready

Page 24 of 46
Figure 21 Manual Match - EXPECTED Selected
You can either run the opposite Enquiry AC.EXP.RECS or simply use the drilldown on the MATCH.WITH
field.
Small Balances Left in ER.BALANCE

When there are match records with in the CCY.AMOUNT tolerances, it is unavoidable that the small
balances will remain on the ER.BALANCE EP.BALANCE fields of the ACCOUNT file although the
Expected fund is fully matched with the Receipt fund. These can be offset with a compensating
receipt/ payment or expected record.
Amounts Matched with Different Value dates

When the expected funds are for one value date but received/payment with an different value date,
then the ER.BALANCE or EP>BALANCE on the ACCOUNT file will have a positive amount for
EXPECTED funds for the expected value date and negative amount for the RECEIPT/PAYMENT
VALUE date. If the tolerance is set then these two will be matched on AC.EXPECTED.RECS but the
ACCOUNT file will give somewhat distorted information. Again, doing two opposite records for the
two dates can rectify this.

Page 25 of 46
Other useful example Enquires

Since the provision of this information does not affect the accounting, interest or charges in T24 the
user will need to evaluate the information via an Enquiry or two. Since we know that the two fields per
value date on Account contain the sum of the amounts receivable and payable (noting the possible
differences caused by tolerance matching), we can apply this to the real account balances and show a
projection of what the account would be like if the amounts are all received as specified.
Whether to use the cleared balance or uncleared balance?

A forward valued item received will impact the uncleared balance today and then the cleared balance
on the value date (or exposure date if set differently). So if we use the cleared balance as a base, a
forward item expected will be included in the projection until it’s authorised then as it won’t be included
in the cleared it will disappear from the projected totals. So it is more appropriate to use the uncleared
balance for this type of information.
The ENQUIRY AC.EXP.BAL below shows there are expected amounts for several days.
Figure 22 AC.EXP.BAL

Page 26 of 46
The ENQUIRY AC.EXP.TOT below shows the information but with a bias towards the records
themselves so we can display more details.
Figure 23 AC.EXP.TOT

Page 27 of 46
The next ENQUIRY AC.UNEXPECTED shows a list of received and expected deals and whether they
are waiting or matched. We can see the deal that is causing the negative figure and have used the
right mouse button to activate a link to a Version, which will create the opposite deal for matching
purposes.
Figure 24 AC.UNEXPECTED
The version, which is called, is a simple one just to create the opposite deal to balance our figures.

Page 28 of 46
Figure 25 Create an opposite deal
Alternatively we can use a dedicated ENQUIRY such as AC.UNEXP, which looks at the received
records that have not been matched. This may be a quicker way of finding the unexpected receipt.
Figure 26 AC.UNEXP

Page 29 of 46
Lastly, there will incoming MT210 messages coming in which are for accounts that are not set-up to
use the AC.EXPECTED.RECS system. We can monitor the incoming messages from
DE.I.HEADER and filter out the ones we do not need to see. Since the transaction reference of the
authorised AC.EXPECTED.RECS record is written back to DE.I.HEADER the Enquiry could be
filtered even more, say to show those that have not been processed in AC.EXPECTED.RECS.
Figure 27 MT210.RECVD
AC.ENRICHMENT
This is a small table, which holds the enrichment for the STATUS values in AC.EXPECTED.RECS.
It is possible that this may be extended to hold other enrichments in T24.

Page 30 of 46
Figure 28 AC.ENRICHMENT - LIST
Batch Processing
The programs AC.EXP.RECS.CLEAR.UNAUTH and AC.EXP.RECS.EOD are run in
SYSTEM.END.OF.DAY2 batch.
AC.EXP.RECS.CLEAR.UNAUTH
This program clears the unauthorised AC.EXPECTED.RECS file and should run daily in the

Page 31 of 46
AC.EXP.RECS.EOD
This program will do all the necessary Close of Business processing and should run daily in the
This will archive records from the AC.EXPECTED.RECS file to the AC.EXPECTED.RECS$HIS file
for those that have reached the value date as determined from the AC.RET.DAYS in the
ER.PARAMETER file for an account and if not defined then the default value from
RETENTION.DAYS.
Calculate the ER.BALANCE for the ER.VALUE.DATE from the records in the AC.EXPECTED.RECS
and update these on the ACCOUNT file, provided the value date is with in the range of
AC.OVER.DAYS for the individual account, if not set then in range of default from OVERDUE as set in
the ER.PARAMETER file.
Delete the records with the STATUS CANCELLED, HISTORY, ARCHIVE, EXP and REVERSAL from
the AC.EXPECTED.RECS file.
Clear the ER.BALANCE and ER.VALUE.DATE from the ACCOUNT file for the accounts not having
any AC.EXPECTED.RECS records.

Page 32 of 46
Additional Usage of AC.EXPECTED.RECS

Correspondent Bank Limit Checking Using AC.EXPECTED.RECS
MT103 messages requesting payments be made by the receiver bank may be received from banks
which do not hold accounts in the currency of the transaction with the receiver bank. The receiver
bank will expect a cover payment to be made by the sender via one of its correspondents, who will
notify the receiver of the cover payment in some way. The payment instruction will be held until the
receiver is satisfied that the cover payment has been made.
T24 can allow payments requests to be automatically authorised, without the receipt of cover payment
confirmation, where a sending bank does not hold a Vostro account with the receiver bank but it does
have a preset allowance. MT195s will be produced to query an unauthorised payment and finally
cancel it (when it has been authorised within an unused limit) if a cover is not received within specified
escalating periods.
To achieve the above functionality, during MT103 inward processing*, in AC.EXPECTED.RECS
application a record is created with FUNDS.TYPE as “EC-Expected Cover” with appropriate Status
based on the limit availability. A record is created in ER.COVER.LIMIT with the Sender’s BIC code
and limit affected to the extent of incoming transaction Amount. FUNDS.TRANSFER contract is
created in Hold or Live based on the available limit with the incoming MT103 details.
In AC.EXPECTED.RECS, cover details received for the MT103 payment can be input manually with
funds type “RC-Received Cover”. When MT103 is received for payment, the system checks for
matching cover details before processing and when matching cover is available the system matches
both “RC” and “EC” record. Otherwise available limit, as defined in ER.COVER.LIMIT for the sender
of MT103 is reduced, to the extent of transaction amount. To match “EC” with “RC” record, matching
criteria in like Account id, Currency, Amount, Value date, Reference etc can be specified in
ER.PARAMETER.
In AC.EXPECTED.RECS application, “EC” records can be created only through inward message
processing. “RC” records can be created through manual input or through an interface using the
statement entry details or cover payment details. The related AC.EXPECTED.RECS id is available
in FT and id of ER.COVER.LIMIT in AC.EXPECTED.RECS for cross-reference.
Using EB.FREE.MESSAGE application, MT195 (Queries) is raised for the unmatched
AC.EXPECTED.RECS during COB batch process for follow-up.

Page 33 of 46
Setup Correspondent limit processing
Step 1:
In FT.APPL.DEFAULT set the AWAIT.COVER as required.

Set to “LIM” to use Limit correspondent checking functionality when inward MT103 is received.
When set to “YES”, then FT’s created through inward processing are always put into HOLD and the
User has to manually check the cover details.
If AWAIT.COVER is left blank then the hold or approve Cover Limit processing is not activated.
Figure 29 FT.APPL.DEFAULT set to allow Cover Limit processing
Figure 30 FT.APPL.DEFAULT set to prevent Cover Limit processing

Page 34 of 46
Step 2
In ER.PARAMETER, add a record with ID as “COVER”. Give the matching criteria for payment
request cover limits and retention days for moving the matched records to history. Id “SYSTEM” record
is used to control the expected payment / receipts (ER/EC) functionality.
Figure 31 ER.PARAMETER with matching criteria for “EC” & “RC”

Page 35 of 46
Step 3
In ER.COVER.LIMIT, specify the limit allotted to a Bank who does not hold a Vostro account. The id
for this application accepts 8,11 characters-Valid BIC code. When a record for the sender of MT103 is
not available in this application, then system automatically creates a record with available Limit as “0”.
To set-up a Limit for a Bank that can be used by all its branches, id has to be created with 8
characters (i.e. without branch code or “XXX”).
Figure 32 System Created Limit in ER.COVER.LIMIT
In the following example a Limit is created for USD 1,000,000 that is available up to 31 Dec 2005 and
covers all the SWIFT branches for that client.
Figure 33 User created Limit with Expiry date in ER.COVER.LIMIT

Page 36 of 46
Step 4
Set the field EXPECTED.RECS on FT.TXN.TYPE.CONDITION for the relevant

FUNDS.TRANSFER FT.TYPE records, note that the inward delivery process may use several
different types according to the message content so set all relevant ones.
Figure 34 FT.TXN.TYPE.CONDION record field EXPECTED.RECS

Page 37 of 46
Step 5
When an Inward MT103 message is received from a Non-Vostro Customer.

Case 1: Customer for whom the limit is not defined in ER.COVER.LIMIT:
It will create a FT on hold and “EC” record in AC.EXPECTED.RECS application with STATUS as
“UA-Unauthorised“. Also record is created in ER.COVER.LIMIT with available limit as “0”.
Case 2: Customer for whom the limit is defined and available

FT record is created and authorised and an “EC” record is created in AC.EXPECTED.RECS with
status as “AU-Authorised”. Limit amount is reduced from ER.COVER.LIMIT for the Customer to the
extent of payment amount.
In the case below since the limit is already defined and available for the customer, the FT is created
and authorised and AC.EXPECTED.RECS is created with STATUS as “AU”.
Figure 35 AC.EXPECTED.RECS with status –AU-Authorised

Page 38 of 46
If the incoming message amount is in excess of any limit amount available then the FT is created on
Hold and AC.EXPECTED.RECS is created with STATUS as “UAL-Unavailable Limit”.
Figure 36 AC.EXPECTED.RECS – with status as UAL-Unavailable Limit

Page 39 of 46
Case 3: Cover details available for a Payment
FT record is authorised and an “EC” record is created and matched with the respective “RC” record
with status as “M-Matched”. However, the limit will not be affected as cover for the payment is
received.
In the following case “RC” record is inputted manually with the reference details.
Figure 37 AC.EXPECTED.RECS with Funds.Type as “RC”
During the processing of an Inward MT103 message, an “EC” record is created with incoming details
and the system matches the “EC” record with “RC” details (as per the matching criteria) and both
records are set to “M-Matched” status.

Page 40 of 46
Figure 38 AC.EXPECTED.RECS with Funds.Type as “EC”-Status Matched
In case FT, which is created through inward processing is changed manually, then relevant
AC.EXPECTED.RECS status is changed to “MA-Manually Affected/ Authorised” and when
corresponding “RC” is received the same is matched.
Matched “EC” / “RC” type of AC.EXPECTED.RECS records are moved to History after the
RETENTION.DAYS as specified in ER.PARAMETER for SYSTEM.ID “COVER”.
In case the “EC” record in AC.EXPECTED.RECS remains unmatched after the number of days as
specified in ER.PARAMETER field REQUEST.ADV.DAYS from the creation date, an MT195 queries
message is sent using EB.FREE.MESSAGE application with the Inward message detailing to the
sender of MT103 the non receipt of Cover funds.
For the example above AC.EXPECTED.RECS record, which is in UAL-Unauthorised Limit status,
after 2 days as specified in ER.PARAMETER and from the date of creation, creates a record in
EB.FREE.MESSAGE with details as received. An MT195 is then sent to the Sender of the original
MT103 message seeking clarification.

Page 41 of 46
Figure 39 EB.QUERIES.ANSWERS for Request query MT195
If the “EC” record remains unmatched after the number of days as specified in ER.PARAMETER in
CANCEL.ADV.DAYS field from the date of creation of AC.EXPECTED.RECS record, then MT195 –
Queries are sent using the EB.FREE.MESSAGE application, informing the cancellation of the
message because of non-receipt of cover funds even after a reminder. The relevant
AC.EXPECTED.RECS record is changed to STATUS “BC-Batch cancelled”

Page 42 of 46
User level query details related to Request / Cancel for field 75 in MT195 can be specified in
REQUEST.QUERY / CANCEL.QUERY at the respective AC.EXPECTED.RECS record level and the
same is used while generating MT195 using EB.QUERIES.ANSWERS application.
Figure 40 Request / Cancel query given at the individual AC.EXPECTED.RECS
If not specified in individual AC.EXPECTED.RECS then query details for MT195 message (field 75)
are defaulted to /2/ for request & /36/ for cancel event.
To process “EC” records that are waiting for cover payment for a RELATED.COVER.ID, after entering
“RC” details in AC.EXPECTED.RECS application, PROCESS.PAYMENTS can be set to “YES”.
Based on the matching criteria as specified in ER.PARAMETER, the system matches unmatched
“EC” record (UAL-Status) with “RC” in online process and the related FT record is authorized by the
system.
During the above process the available cover limit for the ACCOUNT.ID would be increased. To utilize
this available limit for the remaining unmatched “EC” records and to authorize Funds transfer Contract,
while entering “RC” records in AC.EXPECTEDS.RECS application, the field PROCESS.AV.LIMIT
can be set to “YES”.
In case the user wants to skip Limit and matching process during “RC” input, as it involves some time
for processing online, both these fields can be left as Null. In this case The Close of Business batch
process related to AC.EXPECTED.RECS handles the matching and utilization of available limit with
the unmatched “EC” records and the relative FT is authorized.

Page 43 of 46
Regular Receipts
Where a regular set of receipts are expected and to be monitored it is possible to create the receipt
records automatically by using a local routine in the STANDING.ORDER application. Full details on
the setup and use of STANDING.ORDER is explained in the FUNDS TRANSFER User Guide.
To create AC.EXPECTED.RECS on a regular automated basis the following workflow is required.
The ability to create regular receipts is dependent on a few pre-conditions.
Amend or use the correct STO.TYPE
The STO.TYPE used on the STANDING.ORDER must have the use of local routines enabled.
Figure 41 STO.TYPE allowing user routines

Page 44 of 46
Settings in ER.PARAMETER
This should contain the funds types RR (Regular Receipts) and its partner ERR (Expected Regular
Receipts) as required.
These are similar to the standard ER and RECEIPT types but are distinguished due to the method of
creation in STANDING.ORDER.
User Routine
An example called STO.GEN.EXP.RECS is provided as a template for any local developments. In

order to use a different routine the programs should of course exist and be compiled but should also
have a PGM.FILE record with the program name as well.
The user routine is called to create the AC.EXPECTED.RECS record as per local requirements and
should return the id(s) back to the STANDING.ORDER record.
Example STANDING.ORDER
Below is a sample of the STANDING.ORDER being input.
Figure 42 Inputting a STANDING.ORDER for a regular receipt scenario
Certain fields are validated based on the STO.TYPE record having the USER.ROUTINE field set to
yes, and others based on the use of the local routine name placed in the DIARY.DETAILS field.

Page 45 of 46
When the STANDING.ORDER is authorised it will create the AC.EXPECTED.RECS record for the
first instalment, and further ones based on the cycle frequency. They will be matched (fully or partially)
by incoming payments in FUNDS.TRANSFER.
Figure 43 The STANDING.ORDER showing that an AC.EXPECTED.RECS record has been created
Processing of the incoming payments and the creation of the opposite ‘receipts’ are the same as
standard AC.EXPECTED.RECS; this feature is simply a method to create the expected receipts
automatically on a regular basis.

Page 46 of 46

Temenos T24 Ac - Expected.Receipts: User Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Temenos T24 Ac - Expected.Receipts: User Guide

Uploaded by

Copyright:

Available Formats

TEMENOS T24

Information in this document is subject to change without notice.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide

TEMENOS T24 User Guide

TEMENOS T24 User Guide

TEMENOS T24 User Guide

TEMENOS T24 User Guide

AC.EXPECTED.RECS Work Flow

Manual Entry of Expected Funds and Payments

The manual entry of FUNDS.TYPE ER is shown below:

Figure 2 Manual Entry of Expected Funds

TEMENOS T24 User Guide

Manual Entry of Receipt Fund

The manual entry of FUNDS.TYPE receipt is shown below:

Figure 3 Manual Entry of Receipt Funds

TEMENOS T24 User Guide

Auto Creation of Expected Funds from Inward MT210

Figure 4 DE.MESSAGE - MT210 Showing OFS Settings

TEMENOS T24 User Guide

Figure 5 OFS.SOURCE Details

TEMENOS T24 User Guide

Figure 6 Records Created Via Delivery & OFS

TEMENOS T24 User Guide

Workflow creation of Expected FUNDS from SWIFT Inward

Figure 7 Inward SWIFT MT210

The DE.I.HEADER record showing the message has been processed.

TEMENOS T24 User Guide

Figure 8 OFS Formatted - Inward Record

TEMENOS T24 User Guide

Figure 9 Auto Created AC.EXPECTED.RECS from MT210

TEMENOS T24 User Guide

Figure 10 DE.I.HEADER Showing AC.EXPECTED.RECS ID - after Authorisation

TEMENOS T24 User Guide

Automatic Creation of Receipt or Payment Funds Record from FT.

Figure 11 Setting FT.TXN.TYPE.CONDITION to automatic create AC.EXPECTED.RECS

TEMENOS T24 User Guide

Figure 12 Auto Creation of AC.EXPECTED.RECS record from FT

TEMENOS T24 User Guide

Figure 13 Auto Creation of AC.EXPECTED.RECS record from FT with information

Figure 14 Auto Created AC.EXPECTED.RECS

TEMENOS T24 User Guide

Figure 15 FT Input Auto Creation of AC.EXPECTED.RECS

TEMENOS T24 User Guide

Figure 16 FT Record Showing AC.EXPECTED.RECS Matched record’s ID

TEMENOS T24 User Guide

Figure 17 Auto Swift and Ft Created - Matched

New Records in AC.EXPECTED.RECS

Account File Update

When the new record in AC.EXPECTED.RECS is authorised the ER.VALUE.DATE, ER.BALANCE

TEMENOS T24 User Guide

Figure 18 ACCOUNT File Update - ER.BALANCE on ER.VALUE.DATE

Auto Exact Matching Expected with Receipt or Payment

Whenever a new record is authorised in the AC.EXPECTED.RECS the automatic matching

Auto Matching of Expected and Receipt or Payment within Tolerance

TEMENOS T24 User Guide

Figure 19 AC.EXPECTED.RECS Matched information

TEMENOS T24 User Guide

Using Enquiries – AC.EXP.MATCH and AC.EXP.RECS

Figure 20 Manual Match – getting ready

TEMENOS T24 User Guide

Figure 21 Manual Match - EXPECTED Selected

Small Balances Left in ER.BALANCE