ac sweeping and cashpool

TEMENOS T24

Account Sweeping and Multi Level Cash Pooling

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.

Account Sweeping and Multi-Level Cash Pooling

Table of Contents

Introduction.............................................................................................................................................. 3 Account Sweeping............................................................................................................................ 3 Multi-level cash pooling.................................................................................................................... 3

Processing............................................................................................................................................... 3 Account Sweeping ............................................................................................................................... 3 Multi-Level Cash Pooling ..................................................................................................................... 7

Back Valued Adjustments .............................................................................................................. 19

TEMENOS T24 User Guide of 24


Introduction Account Sweeping

Account Sweeping is a mechanism for creating automatic payments across a number of accounts at the COB phase based on the balance reaching a predefined ‘Trigger’ amount.

Multi-level cash pooling

Multi-level cash pooling is an extension of account sweeping where numerous accounts can be grouped together and their balances moved up to a top level account where interest benefits can be gained on the accumulated balance.

Processing

Account Sweeping

This functionality runs off two main tables, AC.ACCOUNT.LINK that defines which accounts are to be linked together in a given sweep, and AC.SWEEP.TYPE, which defines the different styles of, sweep available.

Sweeping happens in the Close of Business during SYSTEM.END.OF.DAY2 in a job called AC.EOD.ACCOUNT.SWEEP. The resulting movements are then stored on the live file AC.ACCOUNT.SWEEP.HIST.

AC.SWEEP.TYPE

Sweep types can be defined with different transaction codes for the sweep or return sweep. There is also the facility to plug in a routine for calculating the amount to sweep. If this routine were not present then the processing would move to do a default sweep to the absolute minimum or maximum value as set on the link record. Lastly for different sweep types you can define the direction of the sweep as Maintenance, Surplus or Two-way.

Maintenance (Standard Sweep)

This sweep involves sweeping from the ‘from’ account to the ‘to’ account when the ‘to’ account falls below its minimum limit.

Surplus (Return Sweep)

This sweep involves the sweeping of funds from the to account to the from account when the balance in the to account goes above the maximum value



Two way (Sweep and return sweep)

This style is simply a Maintenance sweep and a surplus sweep in one link. In this case, the maintenance sweep always goes first.

In all cases, either the amount of the sweep is defined in the API routine or it is enough to bring the balance back to the relevant maximum or minimum amount. The ‘from’ account can never be brought below its minimum amount.

There is also the facility to enable the sweeping mechanism to take into account the limits of the accounts used when calculating trigger amounts. This would mean an account with a trigger amount of £200 and a Limit of £100 would trigger when the balance passed £100. This is achieved by setting the USE.LIMITS field to YES

For return sweeps the funds will always go into the first account in the ACCOUNT.FROM field. However, by setting the field PRIOROTISE.OD you can specify the sweep to clear any overdrafts amongst the ‘from’ accounts first. This would mean that if there were two from accounts with the first having a balance of £200 and the second -£50, the sweep would place £50 in the second account and £150 in the first.

Figure 1 - Maintenance Account Sweep Type



AC.ACCOUNT.LINK

Accounts will be linked through a new table. It will allow multiple to and from accounts to be linked from across multi company environments. You would assign the SWEEP.TYPE for that link as well. The last part of the link would be the relevant minimum/maximum amounts for the ‘to’ account and the minimum amount of the ‘from’ account. The Accounts may be of any currency or customer. If an account has a posting restriction on it then an override will be raised. Similarly you cannot close an account that has an active AC.ACCOUNT.LINK.

Figure 2 - Setting up a Maintenance Sweep for an account

Account Sweeping History

All sweeps will be recorded in a live table called AC.ACCOUNT.SWEEP.HIST. This table is keyed by account and month. It will hold all the sweeps done on that account within the given month. They will be sorted by day swept and accompanied by a unique reference of debit account–credit account–date.



Figure 3 - Historical record of Sweeps



Multi-Level Cash Pooling

The easiest way to envisage a ‘Group’ or ‘Cash Pool’ is that of a family tree like structure. All accounts that would qualify for a cash pool will need to have conditions or rules that dictate when and how much money should be transferred to another account. As mentioned above the purpose of a Cash Pool is to be able to move funds together at a higher level, the proviso to this would be to ensure that accounts lower down in the Group tree remain at a certain level and do not fall into overdraft.

There are currently three styles of sweep, (movement). These are maintenance, surplus and two-way. Maintenance is when an account balance falls below a predetermined level and needs to get funds from another account to ‘top-up’ the balance. Surplus is when an account has excess funds (again above a certain predetermined limit) and moves the excess into another account. A two-way is a combination of the other two; if it is below a limit then get some funds, otherwise put the excess balance to another. The surplus will be extended to enable different accounts to be swept into depending on the balance on the originating account. E.g. If the balance on account A is 900m, move 700m into account B; everything between 700 – 800m goes into account C, and finally any balance over 800m goes into account D. If account A in the example above is in overdraft then the rule will not take effect. There is also another new rule, CASHFLOW rule; CASHFLOW, which in essence allows a two-way rule to have a budget, assigned to it this enabling rule balance monitoring to be used. So an account can be given an amount of 500m to use and it cannot take more than this figure in sweeps unless it adds to it.

There is a parameter file, AC.CP.GROUP.PARAM which users will use to enter the parameters that will control each group that the bank wishes to set-up. There is no constraint on the number of pools that can be in operation, nor is there a restriction on the number of accounts per group. Within the parameter file the user will enter such information as the default balance to use for the pool, the highest level account, (the ultimate target for the funds to be swept up into). There must also be information added as to the type of sequencing to use and whether or not this is a main group or sub-group – discussed later.

As with the account sweeping functionality there are basic conditions or rules available that will dictate what an account does with its current funds. They are Maintenance, Surplus, Two-way and Cash flow. Each rule has its own objective, the Maintenance rule is used to get funds from another account if it’s balance should fall below a certain level. The Surplus rule will place funds above a certain account balance into another account. The Two-way will be a mixture of Surplus and Maintenance; if the balance falls below a certain level then transfer funds into this account otherwise transfer money away to another account. The cash flow rule is more complex in that it involves two balances that the user will initially define , the CASHFLOWDEFINE - the cash flow balance which limits the monetary amount that can be passed down to account B from account A and the aggregate balance which will be a running total of monies passed between the two accounts . These two balances accumulated together set the limit on monies that can be passed down from Account A to Account B at Start of Day; so once a year, (or whenever you choose) account A states that account B has a cash flow balance of 700million. Throughout the year, with a combination of the other three rules, the aggregate balance between A an B is 150 million. This 150 million added to the cash flow balance of 700 million indicates that Account B may receive up to 850 million swept down from Account A. (E.g. there may have been a large dividend paid into a lower level account which has swept up into this higher level account). Until the aggregate balance changes the cash flow balance will now be 850million for this account. It is possible that an account lower down in the pool has had a major mishap and needs to top-up an overdraft by 200million thus reducing the amount that account B has in it’s aggregate balance to -50million DR. In such case the balance now available to Account B is 700 million + 50 million DR = 650 million and this will be the maximum amount that can be used until once again it changes.



Once the parameter file is set the pool is ready to be set. Every account that is to be part of the pool will need to have information added to the new file AC.CASH.POOL, this is where users will enter information unique to this account and detail how this account is to interact with the larger pool as a whole. It will be in the AC.CASH.POOL file that the rule type, (one of Maintenance, Surplus etc) will be entered. Also entered, is the sequence number of this account within the pool. If a sequence of 34 is entered here then this account would be processed after account 35 and before account 33. It is possible to change these sequence numbers at any time while an account is still part of a pool by pool. By entering 72.1 it would inform the system that this account is to be inserted into the tree-like structure after number 72 and before number 73. So the account with the 72.1 entered in the sequence field will become number 73 and number 73 will become number 74. This file will also be used to enter the frequency of each rule entered for an account. This facility gives banks complete control over their cash pools, how they run, when they run and how much each account will contribute to the cash pool.

AC.CP.GROUP.PARAM

In order to start to use the Multi-level Cash Pooling functionality the first thing to do is to define a group on the parameter file that contains basic controlling information. A simple parameter record would look like this:

Figure 4 - AC.CP.GROUP.PARAM record

From the example it can be seen that a group can be defined as either a main group or a sub group, the only restriction being that a sub group must be of the same currency as its main counterpart. Also,



in the example above, this sub-group is to be used for Cash Pooling only. The field SHARED.BALANCES indicated indicates whether a group is for Shared Balances or just Cash Pooling.

Using the Cash pool application, surplus funds in the Cash pool account can be moved to a MONEY.MARKET Contract by specifying the MAIN.MASTER, MAIN.DEPOSIT, OFS.SOURCE and MM.OFS.VERSION in AC.CP.GROUP.PARAM. Money market Contract related information INTEREST.KEY or INTEREST.RATE or INTEREST.SPREAD, CATEGORY, and INT.LIQD.ACCT could be given in AC.CASH.POOL. Using the above information, MONEY.MARKET contracts will be created during End of day Close of Business processing and will be matured in the immediate beginning of day and Principal along with the Interest will be credited as per Cash pool set-up.

AC.SWEEP.TYPE

Released into T24 are a couple of basic rules, which are needed as a minimum system requirement, SURPLUS, MAINTENANCE etc. These can be added to or amended to tailor them for the bank’s specific needs. They are entered into the file AC.SWEEP.TYPE. We can see below that the SWEEP.STYLE has been set to surplus, surplus which means that funds will be placed into another account depending on the conditions entered into the AC.CASH.POOL file. As you can see the BALANCE.TO.USE field is blank. In this case the mandatory field in the parameter file will be used.

Figure 5 - AC.SWEEP.TYPE



AC.CASH.POOL

Once the Parameter file has been set up, the group is effectively ‘Live’, so now is time to assign an account to a group. As you can see below this is a SUPLUS rule to run daily and above 10,000,000. So this rule states that; every business day (FREQUENCY) take any amount over 10,000,000 (MAXIMUM.AMT) from account 16446 (the record ID) up to an amount of 500,000 and put it into account 16478 (LINK.ACCT). The field GROUP.ID indicates that this account (16446) is in the Multi-level Cash Pool Group called “COUNCIL” which is a sub group of the Multi Level Cash Pool Group called “HOUSING”. The bank may want to use more descriptive names, names this would be totally controlled by them.

Figure 6 - AC.CASH.POOL



Figure 7 – AC.CASH.POOL.LINK created from AC.CASH.POOL

Once the cash pool record is authorised then it becomes part of the pyramid sweep and thus is included in the overnight sweeping processes, the frequency deciding when amounts are swept.

The amount to be swept depends on how the cash pool record is set up. For a surplus sweep the MAXIMUM.AMT field becomes mandatory. This is the maximum amount that can be held in the balance specified for the keyed cash pool record. This is what will trigger the sweep. If the balance is above the maximum amount then the sweep amount can be decided in the following order:

1. The OVERRIDE.AMT field.

2. The OVERRIDE.PERCNT field.

3. The AMT.ROUTINE API slot on the cash pool record.

4. The AMT.SWEEP.ROUTINE API slot on the SWEEP.TYPE record.

5. The difference between the maximum amount and the specified balance amount.

No matter what sweep amount is processed from the above, if it is greater than an amount entered in the UP.TO.AMOUNT field then only the value in this field will be swept.

We can specify the amount in MIN.TFR.DR and MIN.TRF.CR, to restrict creation of sweeping entries for a smaller amount.



RTN.WITH.SW.AMT – an interface to user routines

When RTN.WITH.SW.AMT field is set after attaching a local routine in the field AMT.ROUTINE in case of AC.CASH.POOL or in the field AMT.SWEEP.ROUTINE in case of AC.SWEEP.TYPE, the routine will be called after the sweep amount is calculated by the system, before all updates to sweep history and other files are made.

The routine will have the following five parameters:

1. Account balance of TO account before sweep amount is calculated, along with TO account ID

2. Account balance of FROM account before sweep amount is calculated, along with FROM account ID

3. Sweep amount with appropriate sign

4. Cash pool link record and

5. Value Date of sweep transaction

The third parameter, sweep amount will be used by the called routine for further validation as per client’s local requirements and will be passed back to the system for raising the sweep transaction.

If both AC.CASH.POOL and AC.SWEEP.TYPE have routines specified, then the routine in AC.CASH.POOL will take precedence.

INFORMATION SWEEPING

There is an on line application – INFO.GROUP.CP keyed by cash pool group which will display any pending cash sweeps for that day and the resulting account balances for a specified group. No updates are performed by this application. It is purely for informative purposes and can be run many times a day.

ON-LINE SWEEPING

There is the facility within cash pooling to run a group or sub group on line as many times per day as required. A group may be defined to run only once or multiple times per day via its group parameter record. The flag INTRA.DAY may be either SINGLE or MULTI. Single meaning a sweep of this group can only occur once per day, which may be on line or during the overnight batch processing. Multiple means that a group may be swept many times a day as well as during the overnight batch process. A record of all accounts swept is held in the AC.ACCOUNT.SWEEP.HIST application.

In the above AC.CP.GROUP.PARAM example the group COUNCIL may be run many times per day. It is however a sub group, part of the main group HOUSING. The main group may be single or multiple. If the main group was single and run once, it would still be possible to keep processing COUNCIL as many times as was required. If however HOUSING was multiple and COUNCIL was single then no matter how many times HOUSING was processed , the links within COUNCIL would only have been swept the once.



There is a further option in the cash pool record that allows the user to specify where this pool record may be processed. The SCHEDULE field may contain either INTRA; EODCOB or blank. If INTRA then this pool record may only be included in the sweep via on line processing. If it was due to be processed today but no online processing was performed, then during the end of day ,Close of Business the frequency dates would be recycled but no funds would be swept.

If SCHEDULE contains COB then this pool will only be processed during the Close of Business. If left blank then the pool record may be processed both on line and during the Close of Business.

Intra Day Sweep

INTRA.DAY.SWEEP application is used to run sweeps during the day. Sweep can be triggered manually by invoking “V” function for each group in INTRA.DAY.SWEEP. To trigger automatically the sweeping processing, the required schedule time for cash pool group can be specified in INTRA.DAY.SWEEP and once the EB.PHANTOM application is invoked with RUN.ROUTINE as “AC.AUTO.SWEEP.SELECT”, all the cash pool records scheduled for today under the group is executed automatically.

End of Day Sweeping

A link will be included in Close of Business when its frequency date is less then or equal to the processing date and one of the following applies:

1. The SCHEDULE field on its corresponding group parameter record is either blank or EOD.

2. The INTRA.DAY field on the parameter is either MULTI or SINGLE and with no online processing taken place

Sweep Reversals

The REV.GROUP.CP application allows you to reverse and Close of Business cash pool sweep. Enter the group name with the ‘V’ function and all accounts swept during the previous Close of Business run will be reversed. This application does not work with intra day sweeping.

Sweep Reruns

The RERUN.CP.SWEEP application allows you to rerun a sweep only after it has been reversed. It allows the user to enter any back value transactions that may have been omitted from the previous sweep and these transactions will be included in the new sweep. The sweep can only be rerun once. Any transactions entered before the rerun with a value date of today will not be included in the sweep as it is a rerun of the last working day’s sweep only.

Sweep Priorities

During cash pool processing, either Close of Business or on line all cash pool records with a frequency date less that or equal to the processing date will be swept. As there can be many links on one cash pool record you may get the scenario where two links are to be processed on the same day, e.g. a link to run daily will eventually coincide with a weekly link. This obviously would make no sense and so functionality exists to assign each link a priority to dictate which link is to be processed. A



RULE.PRIORITY field exists on the group parameter record and its valid values are ‘FREQUENCY’ and ‘PRIORITY’.

The FREQUENCY option means that during Close of Business when a link date is to be cycled, if a link already exits with the cycled date then the date will continue to cycle until a unique date is found. This therefore eliminates the possibility of two links running together.

The PRIORITY option allows the user to assign priorities to each individual link so should it occur that there is more than one link to process, and then the link with the highest priority wins (1 being the highest). When entering a pool, if its corresponding parameter record is set to use priorities then the user is forced to prioritise each link in the pool.

Shared Balances

Shared Balance processing is an extension of Multi-level Cash Pooling where accounts which are grouped together, as described above, have their combined balances (Balance + overdraft) checked when a transaction is passed across one of the accounts in the group. If the transaction is larger than the accounts balance; and would normally put the account into overdraft then the usual overdraft processing that T24 performs will be extended to consider all the other accounts balances in the group.

If an account is to be part of Shared Balance checking then first a parameter record must be set, first (as described above) with the SHARED.BALANCE field set to YES. Now all accounts entered onto the AC.CASH.POOL file for this group will be considered for cash pooling. If an account is for shared balance checking then on the AC.CASH.POOL file it will have the frequency set to daily and the amount set to 100% of the balance. This is to ensure that during the end-of-day routines all the money that was checked will be moved as expected.

If an account is for Shared Balances then there can be no other Cash Pooling against it and there can be no online movement of funds except during the Close of Business. The one proviso to this is that a sub group could pass funds into a shared balance group which it is not part of.

Back Valued Cash Flow type of Cash Pooling

If the option has been set in the AC.CP.GROUP.PARAM to allow adjustments to sweeps already performed, then when a back-valued entry is passed across one of the monitored accounts the system will create an adjustment. The adjustment could be a new sweep, the cancellation of a sweep, or an adjustment to increase or decrease the amount that swept.

If the result of these adjustments affects another monitored sweep account then that account will also be checked to see if any adjustments are required.

The adjustments are value-dated meaning that each value date from the back value to the current date is assessed for any impact on the sweeps performed.

Ideally any back-value should be processed but given the complex and varying scenarios it would be impractical to expect any system to re-calculate cash pool sweeps for more than a few days, a limit of 31 days has been set. This value can be reduced by setting field BACK.VALUE.CAP on the AC.CP.GROUP.PARAM record.



Example

In this example we will sweep the funds in Account 21784 to 29882 and keep the balance at zero. The only time a sweep may not be needed is if the amount to sweep is less than $10.00, as these would be considered too small to merit the operating costs or any transactional charges the bank may impose.

Figure 8 –Example AC.CASH.POOL

Account before first sweep

The account is primed with a credit of $25,000.00 value 23 AUG 2004. Our expectation is that this will be swept up to the link account tonight.



Figure 9 –ENQUIRY STMT.ENT.BOOK before COB

Account after COB

Figure 10 – ACCOUNT after 1st COB

Here we can see that the $25,000 has been swept out of the account, note the value date of the sweep is the same as the credit date.



Account after new postings

Figure 11 – ACCOUNT after new postings

The entry, which was missed on the 21 Aug 2004, was a debit for $5,000 has now been posted. This means that the sweep that took place was for too much and needs correcting

Account after next COB

Figure 12 – ACCOUNT after next COB with adjustment entry



To correct the over sweep from the previous day an adjustment sweep has now been posted for $5,000. The value date is set to the 9th Sep 2005 so from an interest calculation viewpoint the account has a zero balance, the debit of $5,000 will not cause an overdraft since it is compensated by the adjustment.

A file CORR.GROUP.CP records details of all back value processing. It is keyed on the account number to be back back-valued, the value date of the back value transaction and a sequence number. (It is possible that an account may receive more than one back value transaction.) Each record will hold the details of all accounts re swept as a result of the original accounts new balance.

As many accounts may be affected, the key to CORR.GROUP.CP is help in the account sweep history record of every account included in the back value process.

Figure 13 - Back Value Correction Record



Back Valued Adjustments

Back Valued Adjustment-Non Cash Flow Sweep Type

Discretionary and Non- Discretionary are the two types of back value adjustment set-up in Cash pool, which is explained below.

Back value dated Adjustment in Discretionary Accounts

A discretionary relationship is where the accounts are managed by the bank and are not subject to restrictions such as maximum number of debits. This cash pool set-up is similar to the normal cash pool.

To effect adjustment entries, when there is are back value dated entries in Cash pool accounts, in AC.CP.GROUP.PARAM, the BALANCE.TO.USE should be VALUE.DATED with BACK.VALUE.ADJ set as “Yes”. The AC.CASH.POOL can be created like a normal cash pooling record with the ID and link account along with the sweep condition.

The start date for back value processing is arrived at from the latest among the following:

• Cap Back value date arrived using BACK.VALUE.CAP from AC.CP.GROUP.PARAM.

• LAST.MAINT.DATE, which is available in AC.CASH.POOL.

• Actual oldest back value transaction date.

For example:

• Cash pool record got created on 05th Jun, and then the LAST.MAINT.DATE is 05th Jun. BACK.VALUE.CAP is mentioned as 10 days in AC.CP.GROUP.PARAM.

• On 8th Jun back value-dated transaction done with value date as 01st Jun.

Then start date for back value adjustment starts from the latest of the above, i.e. 05th Jun and the back value adjustment entry will be passed from 5th Jun even though the actual back value dated is 01st Jun.

If any change is done to an existing AC.CASH.POOL record, then the LAST.MAINT.DATE will be updated with current system date and old links details will be ignored for back value date adjustment processing.

Example for Back value dated adjustment for Discretionary Accounts

For Account 123456 Cash pool condition record created to sweep any amount above USD10000 with frequency as Daily. The Cash pool group has the BACKVALU.ADJ Flag is set to YES.



Following are the sweep history details.

DATE BALANCE (USD) SWEEP AMOUNT (USD)

01 JAN 20000 10000

02 JAN 17000 7000

03 JAN 7000 0 (Less than 10000)

On 4-Jan the following back value dated transaction are done:

Dr 123456 Value dated 01-Jan-2002 USD 5000.00

Cr 123456 Value dated 01-Jan-2002 USD 20000.00

Dr 123456 Value dated 02-Jan-2002 USD 5000.00

Cr 123456 Value dated 03-Jan-2002 USD 4000.00

Based on the revised account Balance, the following entries will be passed for Account 123456 with the respective value date.

VALUE DATE

OLD BALANCE

NEW BALANCE

OLD SWEEP

AMT

NEW SWEEP AMT

ADJUSTMENT ENTRY

01 JAN 20000 35000 10000 25000 -15000

02 JAN 17000 12000 7000 2000 5000

03 JAN 7000 11000 0 1000 -1000

Back value dated transaction in Non-Discretionary Accounts

Non-discretionary type of accounts is where there are local requirements governing how many entries can be passed each month over the client’s account.

Following are the requirements of a Bank for Non-Discretionary accounts.

Bank has two type of accounts i.e. DDA &The Bank has two types of accounts, i.e. DDA and MMDA. The surplus in the DDA account is transferred to MMDA and any short fall in DDA, the DDA balance will be transferred from MMDA. There is a restriction on debit entries to the MMDA account of say only 5 entries per month and no such restriction on DDA accounts.



For the above requirement, set the MULTI.RULE as “YES” along with the balance to use as VALUE.DATED and BACK.VALUE.ADJ as “Yes” AC.CP.GROUP.PARAM.

In AC.CASH.POOL, give the DDA account as an ID account and set up the MMDA account as a link account with the sweep type as Surplus and frequency as “Daily”. Based on the restriction on the number of entries, set the appropriate frequency. In this case the number of entries are restricted to 5 –5, hence the frequency is given as “WEEKLY”.

“WEEKLY”

Surplus sweep will happen daily and if there is any back value dated entries to the DDA account, which will result in a Surplus sweep, adjustment entries will be passed along with the normal sweep amount.

Because of the restriction on debits to MMDA, any shortfall in DDA will be passed as a consolidated entry by posting the highest shortfall amount with the value date as the first shortfall date for a given frequency in this case weekly.

When both sweep type frequencies fall on the day, then maintenance will be executed first by posting the highest short fall amount with value date as the first short fall date- if any exists, or from the last maintenance frequency run date, followed by the surplus sweep from the date next to the highest short fall date

Example for Back value dated adjustment for Non-Discretionary Accounts

After all postings up to yesterday have been included in the work files the balance of our example DDA looks as follows:

Balance Requirement USD 5,000

System Date 14th July 2000

DATE BALANCE SHORTFALL

July 10th (11,000) (16,000)

July 11th (23,000) (28,000)

July 12th (8,000) (13,000)

July 13th (8,000) (13,000)

July 14th (8,000) (13,000)

Our work file will have selected the oldest date as July 10th as this is the earliest date where there is a shortfall. The largest shortfall occurs on July 11th so we need to credit the DDA account with USD 28,000 to leave a balance of USD 5,000.



In order to limit the number of correcting entries to pass, this credit will be posted with a value date of the earliest shortfall. If we were checking the balances of the account for each date before the daily sweep job was run this would give a theoretical balance picture as below:

DATE BALANCE SHORTFALL ADJ BY TEMP BAL

July 10th (11,000) (16,000) 28,000 17,000

July 11th (23,000) (28,000) 28,000 5,000

July 12th (8,000) (13,000) 28,000 20,000

July 13th (8,000) (13,000) 28,000 20,000

July 14th (8,000) (13,000) 28,000 20,000

During month end, maintenance sweep will run irrespective of whether maintenance frequency is there or not

.

Any debit reversal to the surplus amount which is already swept will not be allowed as it will break the number of debit transactions to MMDA. However the details of the transaction will be written in the Exception log file with the amount to be reversed along with the AC.CASH.POOL id.

Back value Adjustment details

The regular and back value dated sweep details will be available along with the Debit and credit account balance of Sweep related accounts in AC.ACCOUNT.SWEEP.HIST.



Figure 14 - AC.ACCOUNT.SWEEP.HIST – Adjustment details

Also gives us the original balance and original sweep amount and account balance after back value dated adjustments; adjustments and revised sweep amounts along with the date and adjustment amount entry, which is passed.

The field LAST.MAINT.DATE on AC.CASH.POOL controls how far back any adjustments can be made to. Any entry earlier than that date will be processed as if it equals that date.




This date may be modified if the underlying rules have been modified and the date will be reset to the date the changes are made.

ac sweeping and cashpool

Documents