Management Information

TEMENOS T24
Management Information
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
Overview.................................................................................................................................................. 5
Architecture/Design ................................................................................................................................. 5
Average balances ................................................................................................................................ 7
Structure of the MI parameter files ...................................................................................................... 8
Use of Enquiries and REGENS ........................................................................................................... 9
Departmental hierarchy...................................................................................................................... 10
Creating a departmental hierarchy ................................................................................................. 10
Accessing the departmental hierarchy ........................................................................................... 10
Treatment of inter-departmental balances ..................................................................................... 12
Alternative hierarchy....................................................................................................................... 12
Budgeting ........................................................................................................................................... 12
Guide to Preparing a Budget .......................................................................................................... 13
P&L Adjustments (MI entries) ............................................................................................................ 13
Profit and Loss Allocation .................................................................................................................. 14
Refinancing (Cost of funds) ............................................................................................................ 15
Notional Costs or Margins on Funds (Additional Cost of funds) .................................................... 16
Calculation of transaction unit costs............................................................................................... 19
Calculation of average interest rates.............................................................................................. 20
Allocation of margin on foreign exchange deals ............................................................................ 20
Use of ‘I’ and ‘J’ Fields ................................................................................................................... 20
Choosing between lines when an item falls into more than one .................................................... 21
Detailed Description of internal Selection Priority .......................................................................... 22
‘Drilldown’ to accounts, contracts, and other records .................................................................... 23
Transferring MI data to other systems ........................................................................................... 23
Average balances processing ........................................................................................................ 23
Structure of the Balance Movement (average balances) file ......................................................... 24
Enquiries................................................................................................................................................ 25
Example reports and enquiries .......................................................................................................... 25
GMPR - Department Profitability .................................................................................................... 26
Static Processing ................................................................................................................................... 30
Parameter Files.................................................................................................................................. 30
MI.DATES ...................................................................................................................................... 30
MI.PARAMETER - Application level control ................................................................................... 31
MI.DB.DEFINITION - Specifying the contents of a database ........................................................ 33
MI.SELECTION - Defining groups of records ................................................................................ 36
MI.COLUMN - Defining columns for MI databases ........................................................................ 37
TEMENOS T24 User Guide Page 2 of 105

MI.REPORT.TYPE - Defining line structures for MI databases ..................................................... 38

MI.LINE. - Defining lines on an MI database.................................................................................. 39
MI.BUDGET.TYPE - Categories of MI budget ............................................................................... 40
MI.BUDGET.CONTROL - Creating empty budgets ....................................................................... 41
MI.BUDGET.LINE - user definition of budgets ............................................................................... 42
MI.CATEG.GROUP ........................................................................................................................ 44
MI.ENTRY.TYPE ............................................................................................................................ 45
MI.NETTING.PARAMS .................................................................................................................. 45
MI.UNIT.COST ............................................................................................................................... 46
MI.PL.ALLOCATION - Automatic departmental P & L allocation .................................................. 47
MI.PL.ALLOCATION.2 ................................................................................................................... 49
MI.AUTO.MAPPING ....................................................................................................................... 50
MI.STAT.TYPE ............................................................................................................................... 53
MI.STAT.DEFINITION .................................................................................................................... 53
Transaction Files................................................................................................................................ 57
MI.ENTRY - Internal postings for management information .......................................................... 57
Build Control Files .............................................................................................................................. 58
REBUILD.BAL.MVMT .................................................................................................................... 58
MI.BUILD.DATABASE.................................................................................................................... 59
MI.BUILD.STAT.............................................................................................................................. 61
MI.BUILD.COF.ENTRIES............................................................................................................... 61
MI.AUTO.GEN ................................................................................................................................ 62
Batch Processes ................................................................................................................................ 63
Building Balance Movement ........................................................................................................... 64
Building Profit and Loss Entries ..................................................................................................... 64
Building MI databases .................................................................................................................... 65
Purging ........................................................................................................................................... 65
Database files .................................................................................................................................... 65
Live Files ............................................................................................................................................ 65
BALANCE.MOVEMENT ................................................................................................................. 65
BOOK.DATED.BALANCE .............................................................................................................. 70
BAL.MVMT.BVAL ........................................................................................................................... 71
MI.DATA.XXXXX - The management information database ......................................................... 71
MI.AUTO.ENTRY ........................................................................................................................... 73
MI.BUDGET - The management information budget file ............................................................... 73
MI.STAT ......................................................................................................................................... 73
MI.COF.ENTRIES .......................................................................................................................... 73

Cross Reference Files ....................................................................................................................... 73

MI.AUTO.ENTRY.MONTH ............................................................................................................. 73
MI.STAT.XREF............................................................................................................................... 73
MI.COF.ENTRIES.XREF................................................................................................................ 74
CATEG.PC.MONTH ....................................................................................................................... 74
Routines and programs...................................................................................................................... 74
MI.CALC.INT.RATE - Calculate interest rate ................................................................................. 74
Setup ..................................................................................................................................................... 75
Installation Notes ............................................................................................................................... 75
Parameterised installation .............................................................................................................. 75
Installing BALANCE MOVEMENT (average balances) ................................................................. 78
MI.DATES - Defining the parameter .............................................................................................. 79
REBUILD.BAL.MVMT - Defining the build jobs ............................................................................. 79
Performing the one-time rebuild from history ................................................................................. 80
Batch jobs to automatically update Balance Movement ................................................................ 81
Technical Overview............................................................................................................................ 81
Source Files ................................................................................................................................... 84
Database File ................................................................................................................................. 91
Build Files ....................................................................................................................................... 96
COB Build Routines ........................................................................................................................... 97
Selections .......................................................................................................................................... 98
MI.SELECTION .............................................................................................................................. 98
Enquiry routines ............................................................................................................................. 99
APPENDIX .......................................................................................................................................... 100
Diagrams .......................................................................................................................................... 100
Layout of the MI.BUDGET.LINE text records............................................................................... 100
Overview ...................................................................................................................................... 101
BALANCE.MOVEMENT ............................................................................................................... 102
Profit and Loss Entries ................................................................................................................. 103
Budgets ........................................................................................................................................ 104
Other Source Files ....................................................................................................................... 105

Overview
The Management Information module provides financial management information on customers,
products, departments, including income and expense, average balances, transaction counts and
other information, from which management may analyse profitability and performance.
The system consists of a series of user definable databases, constructed periodically from which
reports and enquiries can be generated. Example reports and enquires are provided to illustrate the
potential uses of the system and to provide prototypes upon which users may base their own system.
The main features of the MI module are:
• Management Information databases containing revenue, volume, cost of funds and other
management information on products processed in the system. The user, including the contents
and values of all columns and lines, defines the content of the database. Existing tools such as
REPGEN.CREATE and ENQUIRY can be used to produce reports from these databases or
they can be exported to other environments such as Excel
• Average balances for all contracts and accounts.
• Budgets.
• Automatic re-allocation of profit and loss between departments.
• Calculation of cost of funds amounts from refinancing rates for contracts and accounts.
• Manual adjustment to MI profit and loss.
Architecture/Design
The basis of the MI system is a series of tables called ‘Databases’. The layout and contents of each is
entirely defined by the user in a suite of powerful parameter files. Any number of databases can be
defined but a typical system might have just three - department, customer, and product, with possibly
a more detailed copy of each for audit.
MI databases are three-dimensional. Columns contain the actual values to be maintained in the
database, e.g. average balance, income, expense, etc. Lines categorise the data into a structure, e.g.
products. Consolidation criteria specify the level of detail that is to be maintained in the database, e.g.
department and team.
The user can also specify what data is to be included in the database, e.g. a customer database might
only be maintained for certain, high volume and important customers.

MI System Design Overview
Each database will be held in a separate file, enabling it to be easily analysed by the tools available in
(such as Enquiry and REPGEN) or exported to other tools such as Excel.
Each database can contain information from the following sources:
• Profit and loss entries CATEG.ENTRY

• Reallocated profit and loss entries MI.AUTO.ENTRY
• Average balance and transaction counts BALANCE.MOVEMENT
• Budgets MI.BUDGET
• Manual adjustments MI.ENTRY
The databases can be held at any frequency though it is expected that monthly will be the most
common.
The databases can be built and maintained automatically during the overnight batch or manually as
required. They may also be rebuilt from any date, perhaps to reflect changes to the database
contents or structure. The only restriction on how far back a database may be rebuilt is whether the
source data in has been archived.
The contents and structure of each database is defined in four stages. Whilst the sequence must
generally be followed, any definition may be modified at any time.

• Define groups of source information MI.SELECTION

• Define the column and their contents MI.COLUMN
• Define the lines and their contents MI.LINE and MI.REPORT.TYPE
• Define the database contents, budget levels MI.DB.DEFINITION
MI.BUILD.DATABASE - controls the construction of databases. It can build databases on-line or

during the batch. The build process reads information from the sources listed above. It then accesses
the four main parameter files listed above and writes information to the databases. This process is
shown in the diagram below.
Flowchart showing process of Database construction
Average balances
The Management Information application has a file called BALANCE.MOVEMENT, which contains
information about all accounts and contracts on by calendar month. The information held is:
• Daily debit and credit movements.

• Back valued daily debit and credit movements.
• Opening and closing balances for the month.

• Average balances calculated on a calendar basis.

• Average balances calculated using the interest basis of the account or contract.
• Daily transaction count.
• (Year-To-Date) average balances calculated for the financial year.
The file has three versions of all balance fields to take account of back valued movements:
• Original. The balances as originally reported by 4 at the time.

• Adjusted. The balances adjusted by back valuations entered before the months closing date.
• Post. The balances adjusted by back valuations entered after the months closing date.
During the month, all balances show month to date figures.
In addition for Accounts, the file can optionally record the Book-dated balances, debit and credit
movements and average balances. When the Post Closing Module is installed, the Book-dated
balances and averages would reflect the status as per the earliest Post Closing (PC) Database
updated for Statement entries with an ACCOUNTING.DATE.
Besides, holding information about all accounts and contracts, the file can optionally hold line balance
of GL reports, debit and credit movements in those lines and their average balances including YTD
balances.
Structure of the MI parameter files

Three main parameter files control the structure of the management information databases.
MI.DB.DEFINITION is the main controlling record - one record per database. It defines a number
of important characteristics of the final database:
Firstly it defines what transactions, accounts, and profit and loss entries are to be consolidated into
this database. It does this using a selection mechanism held on the record.
Secondly it defines at what level of detail the database is to be held. These are called ‘consolidation
components’. For example if the customer number, product category code, and department code are
all specified as consolidation components, then the database will be held at this level allowing
reporting on any of these characteristics. Technically this means that there will be a record on the
database file for each unique combination of the consolidation components.
Thirdly it defines the columns of data that are to be maintained for the database by referencing
records on the MI.COLUMN table. Typical columns might be ‘average balance’ ‘commission
income’ ‘average cost of funds’ etc.
Finally it defines the lines on the database by referencing the MI.REPORT.TYPE table. This feature
enables data to be grouped into meaningful categories and enables data from different parts of to be

associated together. For example it enables profit and loss to be associated with the underlying
business that caused it.
Each of the major parameters offers the ability to specify which information is to be selected for the
database, column or line respectively. The actual selections are held on a fourth file,
MI.SELECTION, so they may be input only once but used many times.
Structure of the MI Parameter Files
Use of Enquiries and REGENS

The MI application provides no physical reports or enquires. Instead it generates databases (called
MI.DATA.XXXX, where XXXX is the user-defined database id) that are available to be analysed
using Enquiry, Repgen or any other similar tools available to the user.
Whichever tool is used, it is important to understand that any report or enquiry should almost certainly
print totals only. This is because the level at which MI.DATA is held will usually be very detailed
(though this of course depends on the users’ specifications) and a report of each individual record will
be too detailed for analysis.
Totalling will usually be based on the consolidation fields and the line field. For example if a database
is held at department level then the field DEPARTMENT will appear on the database. A simple enquiry
might sort the file by DEPARTMENT and MI.LINE and print upon each change of MI.LINE and
DEPARTMENT.

Departmental hierarchy
To produce MI reports at various levels of an organisation, a departmental hierarchy or structure
needs to be specified.
Creating a departmental hierarchy
This is done using the DEPT.LEVEL and DEPT.ACCT.OFFICER applications in the core.
Department level is used to specify the levels of organisation that exist. For example; Department,
Team and Officer.
Each department/account officer is then assigned to one level and linked to its ‘parent’ in the hierarchy.
Thus an individual officer record would be at Officer Level and linked to its Team level. In the example
below the corporate department consists of three teams. The UK team has three officers. Business
can be held against any level of the hierarchy.
Departmental hierarchy structure
Accessing the departmental hierarchy

We have now established a departmental structure. However, in order to be able to reference it, a
further step is necessary. This involves specifying new user fields on various files to contain the
hierarchy information. To do this we use the STANDARD.SELECTION application and a special
user routine called GET.DEPT.LEVEL. See the separate section in this manual for full details of this
routine.
The new field(s) should be added wherever the departmental hierarchy needs to be accessed. The
following tables should be reviewed.

• DEPT.ACCT.OFFICER
• BALANCE.MOVEMENT
• CATEG.ENTRY
• CUSTOMER
• ACCOUNT
• MM.MONEY.MARKET
• FOREX
• LD.LOANS.AND DEPOSITS
• SC.TRADING.POSITION
• MM.MORTGAGE
• LETTERS.OF.CREDIT
• DRAWINGS
• MD.DEAL
• FRA.DEAL
• FD.FID.ORDER
• FD.FIDUCIARY
A first step might be to implement the field(s) on the DEPT.ACCT.OFFICER table itself and then to
produce an ENQUIRY showing the ACCOUNT.OFFICER and the new hierarchy fields. This can verify
the structure and the implementation of the new fields. Once this is working the fields can be added to
the other files detailed above.
In the above example a hierarchy of three levels has been implemented so three fields have been
created. These might be called DEPARTMENT, TEAM, and OFFICER. Department is level 20, team
level 30 and officer level 50. This field is an ‘I’ type and uses the routine GET.DEPT.LEVEL to
retrieve the appropriate code for this record. An example of this part of the standard selection record
is:
Example part of standard selection record

Once this is complete, the field TEAM for an officer record will contain the team the user works in. The
field DEPT will contain the code of the department of which the team forms part.
These fields can now be referenced directly or using J (join) fields on other files such as
BALANCE.MOVEMENT and CATEG.ENTRY.
If the user attempts to retrieve the code for a level lower than the record being processed (for example,
asking for the officer code for a department), the system will use the current code. In this way any
business recorded at department level will appear correctly during officer level reporting.
Treatment of inter-departmental balances

Exclusion of inter-departmental balances is not done automatically by the system. It is therefore
important that any balances that are not to be included in consolidated reports are clearly
distinguished so they can be excluded from the report selection criteria.
Alternative hierarchy
A second ‘alternative’ hierarchy is also provided for organisations that maintain two internal structures,
perhaps one for internal use and one for head office reporting
Budgeting
The MI budget applications provide the ability to maintain annual budgets for any figure on any
database. An unlimited number of ‘budget types’ provides the ability to hold budgets for any amount
(e.g. budgeted income, margin, investment, etc.) and for any purpose (e.g. original budget, revised
budget, etc.). Budgeting may be performed at any level within an MI database. For example if a
database is held at department, team, and product level, its budgets could generally be held at
department level but with certain specific budgets held at team and product level. Budget figures are
automatically consolidated during processing.
For example the budget for the Treasury department is 100M. However, if out of that amount the user
specifically wants to budget 15M for the FX team and out of that 15M budget 5M for the USD spot
product. The following three budget lines will be required:
Line1 Line 2 Line 3

DEPARTMENT Treasury Treasury Treasury
TEAM FX FX
PRODUCT USD Spot
Annual Budget 80 15 5
Example budgeting breakdown

This budget may be created either by directly entering it onto the MI.BUDGET.LINE record for the
year or by entering the outline structure on the database definition record (MI.DB.DEFINITION)
and automatically generating the budget record. The advantage of the latter method is that the same
structure will be automatically generated in subsequent years.
A special feature on MI.DB.DEFINITION enables the automatic generation of empty budget

structures for all combinations, which currently exist on the database. For example, the user could
specify that the basic budget structure is department and product, but that empty budgets are only to
be created for the combinations that exist on the current database. This avoids the creation of unused
combinations such as treasury products against the corporate department.
During the input of budget amounts, additional combinations may of course be added manually.
Budget amounts may be entered directly or a special feature enables the input of the annual amount,
which will then be equally divided over the database periods (such as monthly or quarterly).
Downloading the budget record to a PC allows more sophisticated budget processing. A special
feature converts the budget record to a standard text file (comma delimited) and this may be
transferred to a PC package such as Excel. Budget amounts may be calculated here and the
resulting file uploaded to.
Guide to Preparing a Budget

The steps to establishing an annual budget are:
1. Enter the level at which you wish to hold budgets in the BUDGET.BY fields on
MI.DB.DEFINITION. E.G. Department
2. Enter actual values that you want to budget for in the BUDGET.FOR fields. Two common
choices here would be ‘all’ which means ‘set budgets for all possible values’, e.g. all
departments, or ‘exist’ meaning set budgets for every value that has appeared in a previous MI
database, e.g. all departments that have previously been reported in this database.
3. Enter any budget combinations in the ‘additional’ field. E.g. if you wish to budget for a particular
team in addition to all departments then you might enter 100_101 meaning set a budget for
department 100 team 101.
4. Build the MI.BUDGET.LINE record by verifying a record on MI.BUDGET.CONTROL
5. Input the actual budget figures in MI.BUDGET.LINE. The record is created in ‘hold’ status
and may be amended as necessary before authorisation. The record may, if required, be
exported to another system (perhaps a spreadsheet), amended as necessary and then imported
back into T24
6. Set up a column on the database to report the budget figures and rebuild the database.
P&L Adjustments (MI entries)

The MI.ENTRY application allows the input of manual adjustments that will be incorporated only in
management information reports. MI entries are similar in format to CATEG.ENTRY. Entries on this
file do not need to balance, i.e. debits do not need to equal credits.

A second file, MI.AUTO.ENTRY, is of identical format and use but entries on this file are generated
from automatic facilities such as MI.PL.ALLOCATION. Entries on this file balance, i.e. debits equal
credits. This file is updated by the Profit and Loss Allocation processes (see below) and also from the
generic MI.AUTO.ENTRY generator, the application MI.AUTO.MAPPING, which is used to
generate entries from the statistics file (MI.STAT) and also from the cost of funds file
(MI.COF.ENTRIES).
This file could be used to accept P&L information from systems other than.
MI entries (but not auto entries) are placed in the MI databases by value date. This allows for the
back-valuation of P&L adjustments. CATEG.ENTRY records and MI.AUTO.ENTRY records are
placed by default in MI databases by booking date. However, when the parameter
BUILD.PL.ENTRIES is set to ACCOUNTING in MI.PARAMETER, then CATEG.ENTRY’S with an
ACCOUNTING.DATE would be placed in MI databases by the date of the earliest Post Closing (PC)
database updated by such entries.
Profit and Loss Allocation

Profit and Loss allocation is a means whereby profit and loss entries held on may be automatically
allocated from one department to another. A major use of this facility is cost allocation where the
costs and expenses of running the bank are allocated from one department to support areas, (e.g.
premises, personnel) and processing areas (e.g. cash management, securities) to the end users of the
services, i.e. the marketing areas. It works as follows:
The support areas allocate their budgeted costs to other sections of the bank. For instance, premises
may allocate 30% of their costs to operating areas, 25% to the corporate group, etc.
The processing areas then allocate all their costs on a percentage basis to the marketing groups in the
same way until all costs eventually end up with the marketing areas. These are also the profit centres
to which earnings are attributed, so that cost allocation is a method of relating the cost of earnings to
the earnings themselves.
The user specifies for each department, the P&L category codes and their percentage allocation to
other departments e.g.
Dept. 0001 Information Technology

Category Charge to Precentage DR CAT CR CAT
61000-61010 1010 Treasury Dealers 35% 61098 61099
Salary/Bonus 1020 Treasury Back Office 25%
62000-62030 1030 Corporate 60% 62098 62099
Premises 1100 Personnel 30%
Example of Profit and Loss Allocation

When P&L allocation is run, the total P&L expense (by category) for IT is split according to the
percentages above. MI entries would be raised crediting IT and debiting the other departments.
These entries only appear on the MI system - they are not real accounting entries. They can be
consolidated within the MI reports like any other revenue/expense. The categories to be debited and
credited can be different from the original category where the cost is recorded giving the ability to view
the recharges separately on the MI reports.
This is defined in the MI.PL.ALLOCATION table.
Allocation is repeated on the generated items. Thus an item of expense can be recharged from
department one to department two and, separately onto department three. For example an item of
expense such as premises may be recharged to all departments based on floor-space used. However
an operations department (such as Treasury Back Office) may have to recharge all its costs to
marketing departments based upon an agreed percentage. Thus an item of premises expense would
first be recharged from Finance to Treasury Back Office and then recharged again to the marketing
departments that Treasury Back Office supports.
An advanced form of the Profit and Loss allocation process is defined in the table
MI.PL.ALLOCATION.2, and works on similar principals. However, the MI.SELECTION
MECHANISM is used to define if an item of expense may be recharged. The
MI.PL.ALLOCATION.2 table defines a series of rules, which are referenced by the category and
MI.CATEG.GROUP tables, and each Profit and Loss entry is compared to the rules for its category
and MI.CATEG.GROUP.
Refinancing (Cost of funds)

Refinancing is the calculation of interest income or expense net of the cost of funding the deal. For
example if the corporate department makes a loan to a customer at 4.5% and this is funded at 3.75%,
refinancing will calculate the interest income at a net rate of 0.75%. This figure is available for
analysis in the Management Information databases.
If the contract is in the Money Market, Mortgage or Loans and Deposits applications then the
refinancing rate will be taken from the deal itself if it has been entered. In case of an Account,
refinancing rates will be taken from the record for the Account in the file MI.COF.ACCOUNT. In all
other cases the refinancing rate will be allocated from a default specified on the MI.PARAMETER
table. This default can be allocated based upon characteristics of the deal.
The user can specify different rates for Debit and Credit refinancing. For instance if a major account
were in credit for part of the month, the rate placed on this money on the market might be different to
the rate the user would be charged to fund the account in overdraft.
The exception is for refinancing rates input on individual deals - each deal is either a Placement or a
Deposit, so only needs one refinancing rate.

The refinancing information may be included in the MI databases in three ways, either as an average
refinancing rate, as a refinancing accrual amount, or as MI.AUTO.ENTRY records.
The average refinancing rate can be included in a database by specifying a column whose source is
BALANCE.MOVEMENT>REFIN.RATE.DR and which has a column type of INT.RATE.
Specifying a column record can be used to include the refinancing accrual amount.
Specify refinancing accrual amount
The net interest accrual can be calculated in the reporting tool by subtracting the refinancing accrual
from the real accrual.
Another way in which the refinancing information may be included is via the file MI.COF.ENTRIES -
which is used as a source file to create records on the MI.AUTO.ENTRY file which may then be
included within the database. Each MI.COF.ENTRIES record will create a pair of balancing
MI.AUTO.ENTRY records, which will debit the funded profit centre and credit the funding profit
centre.
Notional Costs or Margins on Funds (Additional Cost of funds)

It may be required to calculate additional costs/margins such as Liquidity charges on the Funds
deployed for Accounts and Contracts, which are in addition to the refinancing costs; these additional
costs could have a different Funding Dept.

The parameters for each type of Additional Cost of Funds could be specified using the file
MI.COF.TYPE (Parameters for refinancing are in MI.PARAMETER).
MI.COF.TYPE Record
The IDs of MI.COF.TYPE file could be specified in individual contracts in the applications LD, MM
and MG and for Accounts in MI.COF.ACCOUNT. They could be also specified along with
refinancing Pool rates in MI.PARAMETER.
If the contract is in the Money Market, Mortgage or Loans and Deposits applications then
Rates/Funding Dept. for the additional costs will be taken from the deal itself and in case of Accounts
from the record for the Account in the file MI.COF.ACCOUNT, if they have been entered.

MI.COF.ACCOUNT Record
If both Refinancing rates and Rates for Additional Cost of Funds are not defined for an individual
Account/Contract, then both would be defaulted from the Pool Rates if defined in MI.PARAMETER.
In case only Refinancing rates are defined for an Account/Contract as Matched Funding rates and
details of additional Cost of Funds are not defined for the Account/Contract, then would not calculate
any additional Cost of Funds.
The following table explains the various combinations possible for specifying refinancing and
additional Cost of Funds details and the calculations done by.
Refinancing Additional Cost of Refinancing Additional Cost of
Rates/Dept Funds Rates/Dept Rates/Dept used in Funds/Rates used in
Calculations Calculations
Defined for an Account Also defined for the Rates/Dept defined for Rates/Dept defined for
or Contract as Matched Account or Contracts the Account or Contract the Account or Con
Funding Rates as Matched Funding
Rates
Defined for an Account Not defined for the Rates/Dept defined for Not Calculated
or Contract as Matched Account or Contract the Account or Contract
Funding rates
Not Defined for an Defined for the Account Rates/Dept defined as Rates/Dept defined for
Account or Contract or Contract as Matched Pool Rates in the Account or Contract
Funding Rates MI.PARAMETER
Not defined for an Not defined for the Rates/Dept defined as Rates/Dept defined as
Account or Contract Account or Contract Pool rates in Pool Rates in
MI.PARAMETER MI.PARAMETER
Table for Refinancing/Additional Cost of Funds Specification Rules

The user can specify different Pool rates for Additional Cost of Funds on Debit and Credit Balances in
MI.PARAMETER as well as for the individual Accounts defined in the file MI.COF.ACCOUNT.
The exception is for additional Cost of Funds rates input on individual deals - each deal is either a
Placement or a Deposit, so only needs one rate.
The additional Cost of Funds information may be included in the MI databases similar to that of
Refinancing information.
When MI.AUTO.ENTRY are generated from MI.COF.ENTRIES for COST Type Additional Cost of
Funds, then the Originating Dept. would be debited and Funding Dept. would be credited irrespective
of the type of Balance on which the Cost of Funds is calculated.
Calculation of transaction unit costs

The unit cost facility within the module is based upon P&L entries (category entries in terms) and the
transaction codes on them. For each P&L entry the system is able to allocate a ‘unit cost’, which you
specify on the TRANSACTION table.
For example, the user inputs a payment order and makes a charge of $30. This generates an income
category entry for $30. This category entry has a transaction code (which you defined on the
FT.CHARGE.TYPE table), for example ‘Payment Order Charge’. If the user entered a unit cost
against this transaction code of $22, then MI is able to report the charge, the unit cost and the
difference of $8. It can of course report this by department, customer, line (product) etc.
So you are able to specify and report on unit costs wherever you make direct charges.
Further thought shows that we can divide ‘transactions’ into four categories as follows:
• Transactions for which a direct charge is made, e.g. foreign currency payment order, i.e. those
that MI can support.
• Transactions for which an indirect or no charge is made, e.g. Loan where there is no charge
(making our money from the interest margin only).
• Transactions recorded on for which no charge is made, and no accounting is performed, e.g.
statement reprint.
• Transactions not recorded on, e.g. manually prepared tax statement.
The first of these types of transactions are included within the Management Information system as
described above, while the others may be included via the MI.STAT file. Refer to the
MI.STAT.DEFINITION section for further details.
Before using the unit cost facility you may wish to examine your current parameters. You need to
ensure that you are able to distinguish between the various charges by the transaction codes on their
category entries. It is possible that you currently record activities with very different costs using the
same transaction code. For example, you may record the charges for the negotiation of foreign
cheques and local cheques using the same transaction code of Cheque Negotiation Charge. If this is

the case then you will not be able to record the different unit costs for the two activities.
Calculation of average interest rates

The MI application does not hold average interest rates; however they can be calculated from the total
accrued interest and the average balance. The reporting tool (such as ENQUIRY or
REPGEN.CREATE) can then easily calculate the average balance.
For example the following line might appear on a monthly department profitability report:
Avg.Bal Interest Income Avg. Rate

Medium term loans 25,000,000.00 174.10 8.2%
The average rate is calculated from the average balance of 25M and the interest income of 174T. The
average balance comes from the BALANCE.MOVEMENT file and the interest income comes from
the CATEG.ENTRY file.
The formula used is:

Interest income * Days in year*100
Average Rate =
Average balance * Days in period
The “days in year” and “days in period” are calculated by MI and held on the databases. If the MI
database contains mixed interest bases (e.g. Sterling Gilts and US Treasury Bills have been
accumulated together), then the days in year and days in period will be based upon the local currency
interest basis.
Allocation of margin on foreign exchange deals
The FOREX application has a facility that enables the input of a treasury exchange rate to each deal.
This is the rate at which the deal is funded and, when this deal is input, additional P&L entries will be
generated for ‘marketing exchange profit and loss’ - the P&L earned by the department who did the
deal. This is calculated from the margin between the treasury and the deal rate.
Like all P&L entries, these will be held on the file CATEG.ENTRY that is passed to the MI application.
This enables the MI application to correctly allocate the profit to the marketing and treasury
departments.
Use of ‘I’ and ‘J’ Fields

The T24 Management Information application makes extensive use of the facilities of J descriptor
fields and I on STANDARD.SELECTION. These facilities allow the user to add new fields to
existing files.

They are especially used to add new analysis fields to the two main files that MI is based on -
BALANCE.MOVEMENT and CATEG.ENTRY.
I descriptors allow the addition of new fields that are based upon other fields on the file. This has
many uses but the main one for MI is to create common field names that can be created across
different files. For example the field containing the category code has a number of different names in
the various contract files, so an I descriptor called ‘PRODCAT’ has been created that will simplify field
specifications in MI.
J descriptors allow the addition of new fields that contain data from related files. For example a
customer owns all accounts and contracts on the BALANCE.MOVEMENT file but the record itself
contains no further information about the customer. To enable analysis by type of customer, the
SECTOR from the CUSTOMER record may be added to BALANCE.MOVEMENT using a J
descriptor field.
Choosing between lines when an item falls into more than one
When a database is specified, as having ‘UNIQUE.SELECTION’ then each item of data will be added
into one and only one line; however it is possible that an item of data will match the selection criteria
for more than one line. For example we have two lines - ‘Current Accounts’ and ‘Current Accounts for
Banks’. A current account for a bank could be placed in either line - it is both a current account and a
bank’s current account. Obviously we want to choose the latter but how do we ensure that MI
understands our intentions?
MI offers a mechanism called Selection Priority.
Firstly there is a field on the line description (MI.LINE) where we may input the line’s priority. In the
case of the above example, we could give the line ‘Current Accounts for Banks’ a higher priority than
‘Current Accounts’. MI would then check the lines in priority sequence. Finding a match against
‘Current Accounts for Banks’; it would allocate the item to this line and look no further. We have
achieved a correct result.
However allocating a manual selection priority to all lines would prove tedious. Consequently MI
offers an automatic facility to default the selection priority based upon an analysis of how specific the
definition of the selections is.
Again in the above example, ‘Current Accounts for Banks’ is a more specific selection than just
‘Current Accounts’ and records would be compared to this first. The same result would have been
achieved as when the priorities were allocated manually.
MI’s determines how specific a selection is by analysing the number of different operands and fields
used in the selection. This process is described in more detail below.

Detailed Description of internal Selection Priority
MI holds the sequence in which it will check lines in the field INT.SEL.PRIORITY on MI.LINE. This
field consists of two parts: the SELECTION.PRIORITY as input by the user and an analysis of the
relative specificity of the selection parameters for the line.
MI determines the relative priority of lines by analysing the MI.SELECTION records that the
MI.LINE record refers to. It examines three factors:
• The number of different source fields used in the selection records

• The number of different operands used on those fields
• The relative priority of those operands (see the table below)
For example if MI is presented with two lines with the following selections:
LINE 1 – PRODUCT EQ 1000

LINE 2 – PRODUCT EQ 1000 AND CATEGORY EQ USD
It will assign data to line 2 if it matches. Only if it does not match here will it check against line 1.
MI holds its assessment of the relative priority of each line in the field ‘internal selection priority’ on the
MI.LINE record. This consists of a three-digit number. The structure of the field is:
ABC Where :
A - is taken directly from the selection priority fields as entered by the user
B – number of selections is the number of selections specified for this line (to a maximum of 9)
C - is a value based on the operands used in the selection as defined below
Operand Meaning Allocation
Priority
EQ Equal 9
LK Like 8
RG In range 7
LE Less than or equal to 6
GE Greater than or equal to 5
LT Less than 4
GT Greater than 3
NR Not in range 2
NE Not equal 1
Comparison operators

‘Drilldown’ to accounts, contracts, and other records

The system does not maintain an automatic link between management information databases and the
contracts and accounts. Consequently it is not normally possible to view a figure in the management
information system and ‘drilldown’ to the contracts, accounts or other records from which it was built.
However should this be required then a special technique can be employed to do this called an ‘audit’
version of a database.
An audit database is one which analyses the same information as the main database but which holds
it at a lower level of detail. For example an audit version of a department level database might further
analyse the same information by product and customer. Enquiries and reports can then be produced
showing a greater level of detail than normal for investigative or analysis purposes. Using Enquiry, the
two levels can be linked enabling a detailed breakdown to be presented on-line.
The reason for creating two databases is performance. It is much quicker to produce regular reports
at the higher level and only to use the lower (and much larger) audit database when specific low level
analysis is needed.
A special case of audit database is one that is at the individual id level of the source data. Each
record read from and accumulated into the database has its own record written to this audit database.
This database can then be used to link back to the source records.
This low level of detail is achieved by specifying the @ID of the source records as one of the
consolidate fields in the definition of the audit database. This field can then be used in enquiries to
display the source record.
To do this it will also be necessary to hold the source file as one of the columns in the database. This
can be obtained from the field SOURCE.FILE on all source files.
Transferring MI data to other systems
The MI database is stored in a multi-value format which is difficult for other systems to read directly.
T24 provides tools to extract data for transfer to PC systems such as the ENQUIRY sub-system, if
these are not suitable then bespoke extract programs may need to be written depending on the
system receiving the data.
Average balances processing
Central to the operation of the MI system is the average balance mechanism. Average balances are
held in the application BALANCE.MOVEMENT along with other management information such as
transaction counts. The BALANCE.MOVEMENT file is created in the following stages:

• Daily analysis of movements across accounts and contracts

• Occasional transfer of movement data to the BALANCE.MOVEMENT file
• Occasional calculation of average balances for BALANCE.MOVEMENT records
• Occasional calculation of refinancing rates for BALANCE.MOVEMENT records
Normally these jobs will be run during the overnight batch run. The first job must be run each day but
the other jobs can be run when required. They may also be run at the very end of the batch run, after
the system is on-line and available for input. In this way the overnight run-time is not increased.
The last three stages can be rerun from a user specified date in the past, thus enabling the
BALANCE.MOVEMENT file to be rebuilt if required.
Structure of the Balance Movement (average balances) file
The BALANCE.MOVEMENT file contains the following types of information:
• Opening and closing monthly balances

• Balance movements during the month
• Transaction
• Average balances including YTD balances
• Refinancing (cost of funds) rates
All the information except the transaction counts and refinancing rates are held in three forms
depending on back-valued entries:
• Original
• Adjusted
• Post-adjusted
Original means as the account or contract stood during and at the end of the month. Adjusted takes
account of entries back-valued into the month before the month’s closing date. Post-adjusted takes
account of all subsequent back-valuations into the month.
The following examples show the effect on the opening and closing balances of entries booked during
a month, during a month’s adjustment period, and after a month has closed.

Examples of opening and closing balances of entries booked during a month
Note particularly that the terms adjusted and post-adjusted when applied to the opening balances for a
month refer to the closing date for that month, not the previous month. Thus it is perfectly possible for
the closing adjusted balance for June not to equal the opening adjusted balance for July. The
difference is entries input during July’s adjustment period and back-valued before the end of June.
In addition, for Accounts the average balances based on booking date could be populated in the
BALANCE.MOVEMENT records, if the parameter BUILD.BD.BALANCES is set to YES in
MI.PARAMETER. When an ACCOUNTING.DATE is specified in STMT.ENTRY records, the Book
dated related balances and averages would be based on the date of the earliest Post Closing (PC)
database updated by such entries. The BALANCE.MOVEMENT records should be rebuilt after
applying the Post Closing entries to the PC database to ensure that the Booking date averages and
balances are calculated in sync with the Post Closing database.
Enquiries
Example reports and enquiries
This section provides some examples of MI databases that can be created and reports and enquiries
that can be produced. The examples are released with the demonstration system for you to amend
according to you requirements.

GMPR - Department Profitability
The GMPR (Group Management Profitability Report) reports the profitability of the bank’s
departments. The enquiry below displays analysed information from the GMPR database.
Each line is a category based on the type of product and income or expense. Each line is analysed by
the following columns:
• Volume – Average balance (after post-closing adjustments) in local currency

• Revenue – Total interest income or expense in local currency
• Cost of Funds – Interest accrual equivalent based on the refinancing rates allocated to the
accounts and contracts in this line.
• Net – Difference between revenue and cost of funds
• Budget – Budgeted income or expense for this line
• Variance – Percentage variance between revenue and budget
• Average rate – The average interest rate for the accounts and contract in the line. Calculated
from the total interest income, expense and the average balance.
• Refinancing rate – The average refinancing (cost of funds) rate allocated to the accounts and
contracts in the line
• Margin – Difference between the average and refinancing rates.
Enquiry details for “GMPR – Department Profitability”
Further analysis of individual figures is available by drilling down to lower level enquiries. Thus if we
want to know how a particular line from the above enquiry was constructed we can drilldown to the
audit enquiry shown here:

Drilldown to audit enquiry for further analysis
From here we can drill down further to the associated underlying transaction or category entry.
The GMPR ENQUIRY can be linked to an Excel spreadsheet by using the Graphical User Interface
and its DDE capabilities. This offers many further possibilities for analysis and manipulation, one
example of which is the use of Excel pivot tables as shown below:

Link the GMPR Enquiry to an Excel spreadsheet
Two databases were created to support the above examples. They were:
GMPR – Main database consolidated by department, team, product and customer

GMPA – Audit database consolidated by department, team, product, customer and source id. Source
id is the id from the T24 records from which the database was created
The database definition for the GMPR database is:

Database definition for GMPR
The audit database GMPA uses the same report type and the same columns however an additional
consolidation field (SOURCE.ID) specifies that the database is to be built at a very detailed level, the

level of the table from which the database is being build. This enables a detailed breakdown of the
GMPR database and a link back to the system for reconciliation and investigation.
Static Processing
Parameter Files
MI.DATES
This parameter has one record for each company, keyed by the company code, and performs the
following functions:
• Determines whether average balances are required.

• Determines how many months average balance data is held by the system.
• Specifies the default closing date of a month, allowing manual overrides for each month.
• Holds the date on which the BALANCE.MOVEMENT file was last updated.
• Holds the date on which the calculation of average balances was performed.
• Holds the date on which the P & L allocation process was performed.
• Holds the date on which the Cost of Funds entry generation was performed.

MI.DATES parameter record
MI.PARAMETER - Application level control

This table stores the top-level parameters to control the MI module (one record SYSTEM). This
parameter is used to specify the amount of MI history the system is to hold and the default refinancing
and additional Cost of Funds information. The current base currency of the MI module is also held
here.
To facilitate the scope of MI data maintenance, it would be possible to specify which types of Average
Balances need to be maintained in BALANCE.MOVEMENT and for which applications
BALANCE.MOVEMENT related data needs to be maintained.

By specifying SC or ALL in BAL.MVMT.APPS of MI.PARAMETER, the BALANCE.MOVEMENT

data for Securities transactions in Banks Portfolios would be maintained. However, to maintain
BALANCE.MOVEMENT data for Securities transactions in Customer Portfolios, in addition the
parameter BUILD.CUS.PORT in SC.PARAMETER should be set to YES.
The default refinancing rates and additional Cost of Funds information are held in the group of fields
from SELECTION to ADD.COF.DEPT.
Refer to the Para “Notional Costs or Margins on Funds” on the rules for defaulting refinance and
Additional Cost of Funds information. To find the default refinancing rate and additional Cost of Funds
information, the system will take the account or contract and compare this to the MI.SELECTION
records defining each group of default rates. When a match is found, the rates and information
specified on that group will be applied to the account or contract. If no match is found then a rate of
zero will be applied for refinancing and no Additional Cost of Funds information will be defaulted. If
this is not required then a ‘catchall’ selection should be specified last. This will apply the specified
rate/information to all accounts and contracts that did not fall into the categories specified further up
the list.
Optionally, in addition to holding information about accounts and contracts, BALANCE.MOVEMENT

can be made to hold GL line balances as well by specifying the names of the reports in
GL.BAL.REPORT.

MI.PARAMETER Record
MI.DB.DEFINITION - Specifying the contents of a database

This table contains the main definition of each Management Information database.
It specifies:

• The records that are to be included in the database.

• The columns that are to be maintained.
• The line structure that is to be used.
• What level of detail (consolidation) is to be kept in the database
• The frequency of the database - whether the database is daily, weekly or monthly.
• Whether budgets are to be held for the database and, if so, at what level.
It also contains information on the last time the database was built for each company and for each
type of file, which has been processed (e.g. average balances, P & L entries and Budget information).
For example, the MI.DB.DEFINITION record for the customer profitability (CP) database might
state that only information for certain types of customer is to be included (identified by the sector of the
customer) and that the customer’s id and the account officer responsible for the customer are to be
passed forward to enable further analysis, and that columns are to be held showing average balance,
interest income, and non-interest income.
Upon authorisation of the MI.DB.DEFINITION record the application will automatically create the
new management information database (the MI.DATA.xxxx file) and its associated
STANDARD.SELECTION record.

MI.DB.DEFINITION Screen to specify the contents of a database

MI.SELECTION - Defining groups of records

Used to define categories of records for use whenever records are be selected throughout the MI
application. The file is referenced when records are being selected for databases, for lines and for
columns.
MI.SELECTION screen to define groups of records
MI.SELECTION records may also be combined together to form other useful groups.

Combine MI.SELECTION records together to form other useful groups
MI.SELECTION records can refer to other MI.SELECTION records. This enables individual
selections to be specified once only and then grouped together under other records making more
powerful selections. Subsequent maintenance is simple because the specifications are only defined
once. An example of a group of selection records might be:
Thus if a modification is made to the definition of money market deposits (perhaps by the creation of a
new and unanticipated category code) then only one record needs to be maintained (MMDEPOSIT)
and all references to it or to DEPINT are automatically updated.
MI.COLUMN - Defining columns for MI databases

This table defines the columns that are available for use within the MI databases. Each record
describes a single column.
The record defines the records that are to be selected for inclusion in this column (for example if the
column shows ‘Commission Income’ then the record will specify which P&L entries are to be included).
The record also defines the field on where the data is found (indicating, for example, that ‘number of
transactions’ is found in the transaction count field on the BALANCE.MOVEMENT file whereas
‘income’ is found in the LCY.AMOUNT field on the CATEG.ENTRY file).
The record also defines the characteristics of the resulting field such as its name, editing formats etc.

MI.COLUMN Screen for defining columns for MI databases
MI.REPORT.TYPE - Defining line structures for MI databases

This table defines the various line structures that are available for use within MI databases. For
example a typical line structure might be ‘Summary customer profitability report’.

MI.REPORT.TYPE Screen to define line structures for MI databases
MI.LINE. - Defining lines on an MI database

This table defines the lines within an MI report database. Each record defines a single line on the file
providing a narrative description and selection criteria that will be used to determine which
information is consolidated into this line.

The id is the MI.REPORT.TYPE.ID and the line number e.g. SCPR.0001.
MI.LINE screen to define lines on an MI database
MI.BUDGET.TYPE - Categories of MI budget

This table stores categories of budget. For example a typical range of budget types might be:
• DP Departmental performance budgets
• DA Adjusted departmental performance budgets
• CB Customer performance targets
MI.BUDGET.TYPE screen to show categories of MI budget

MI.BUDGET.CONTROL - Creating empty budgets

This file controls the creation of empty budgets.
Verification of a record on this file will cause MI to examine the budget specifications on
MI.DB.DEFINITION and MI.BUDGET.TYPE and to create an empty budget record on
MI.BUDGET.LINE waiting for input of budget amounts.
For example if you have specified on MI.DB.DEFINITION that budgets for this database are to be
specified for each department that already been reported in the database, verification of the
MI.BUDGET.CONTROL record will cause the system to analyse the database looking for all
departments and the information reported for them. It will then create an ‘empty’ MI.BUDGET.LINE
record. This record is then available for input of budget amounts for the period and, if required, for
other amendment such as the addition of new departments, deletion of departments, etc.
MI.BUDGET.CONTROL will examine the following specifications:
• The consolidation values to be budgeted for as specified in the BUDGET.FOR fields on

MI.DB.DEFINITION.
• The frequency as specified on MI.DB.DEFINITION.
• The lines that are to be budgeted for as specified in the budgeted field on MI.LINE.
The MI.BUDGET.LINE record will be created held, ready for user input of budget amounts.
MI.BUDGET.CONTROL for creating empty budgets

MI.BUDGET.LINE - user definition of budgets

This is the file where budget amounts are input. It can be created automatically from the budget
structure details on MI.DB.DEFINITION or can be input manually. The file contains sections for
each ‘BUDGET.FOR’ category (e.g. a department), line and period. The file can be downloaded to a
PC and the budget amounts input there if required.

MI.BUDGET.LINE screen for user definition of budgets
This file allows the user definition of budgets for use within the Management Information system.

The amounts can then be defined for each report line and area without the need to enter the report
line details.
Verifying the record will provide the option of down loading or uploading a text record to / from disk,
from the path specified on the record. This allows the definition of the budget to be carried out on
another system, possibly a spreadsheet on a PC, and then imported back into, while the download
facility means the report lines and areas to be budgeted for will be represented on the spreadsheet.
Authorisation of the record will cause previously created records to be removed from the
MI.BUDGET file and a flag set on the record. If this flag is still present at the time of the database
build for which the budget is held, then the MI.BUDGET records will be created automatically.
Additionally, the user may force the MI.BUDGET records to be created at any time, by authorising
the record with the user rebuild flag set to yes. Once the process is complete, both the
USR.REBUILD.BUDGET and the SYS.REBUILD.BUDGET fields will be set to null.
Reversal of a MI.BUDGET.LINE record will remove the previously automatically generated records
on the MI.BUDGET.FILE.
MI.CATEG.GROUP
This table is used to group together categories to simplify the processing of entries within the MI
module and to associate rules for advanced P & L allocation via the MI.PL.ALLOCATION.2 file
(see MI.PL.ALLOCATION.2).
Records on this file are referenced from the CATEGORY application.
MI.CATEG.GROUP screen to group together categories to simplify processing of entries

MI.ENTRY.TYPE
This table is used to define the type of profit and loss entry being processed within the MI module, and
is found as a field on the MI.AUTO.ENTRY and MI.ENTRY applications. This information only
appears on P & L entries.
The MI.ENTRY.TYPE of a CATEG.ENTRY record is found as a default from the PL.CATEGORY

- linking to the CATEGORY file to retrieve the MI.ENTRY.TYPE - but may be specified for types of
P & L entry, as defined on the following applications:
MI.PL.ALLOCATION.2
MI.PARAMETER - for use on the MI.COF.ENTRIES file
MI.ENTRY.TYPE screen to define type of profit and loss entry being
MI.NETTING.PARAMS
This table is referenced by the following applications:
MI.PL.ALLOCATION
MI.PL.ALLOCATION2
MI.AUTO.MAPPING
It is used to define the netting criteria on which entries on the MI.AUTO.ENTRY file will be created.
The fewer the fields defined in NETTING.FIELDS the lower the number of records will be created.
Each pair of records to be netted, are processed together.
The following netting fields are mandatory:
• VALUE.DATE

• BOOKING.DATE
• ACCOUNT.OFFICER
• CURRENCY
• PL.CATEGORY
In addition, the ACCOUNT.OFFICER of the balancing entry is considered to be a mandatory field,

which cannot be defined. This field is always considered as a netting field.
When defining the netting criteria for use in the MI.PL.ALLOCATION and MI.PL.ALLOCATION.2
applications, it is possible to specify various different types of netting. However, performance will be
improved if the number of different MI.NETTING.PARAMS records specified is low.
MI.NETTING.PARAMS screen to define netting criteria
MI.UNIT.COST
The records on this file are used within the MI application to assign costs as at a certain date. The file
is referenced by MI.STAT.TYPE to assign a unit cost to the defined activity.
The costs held on this file are specified in local currency.
Before the unauthorised record is committed the record is sorted by date, such that the most recent
cost is at the top of the record.

MI.UNIT.COST record for assigning costs as at a certain date.
MI.PL.ALLOCATION - Automatic departmental P & L allocation

This table holds the allocation details for allocation of profit and loss entries within departments. It will
be used to automatically create entries on the MI.AUTO.ENTRY file, which reflect the re-allocation
of profit and loss entries amongst departments within an MI database. These entries may be netted
according to the criteria defined in the MI.NETTING.PARAMS application. Refer to that section for
details.

MI.PL.ALLOCATION screen for automatic departmental P & L allocation
For example, there is a requirement to recharge the cost of rent on premises to two departments, 100
and 200, at 30% each. The MI.PL.ALLOCATION record might look as follows:

Example of MI.PL.ALLOCATION recharge
This would cause the following entries:

Amount Dept Category Comment
£50,000 dr. 900 61001 Original CATEG.ENTRY record to Financial Control
£30,000 cr. 900 61900 Netted recharges taken from Financial Control
£15,000 dr. 100 62400 Amount recharged to Treasury
£15,000 dr. 200 62400 Amount recharged to Corporate
Entries as a result of MI.PL.ALLOCATION recharge
MI.PL.ALLOCATION.2
This application is similar to the MI.PL.ALLOCATION application in that the file contains records,
which are used by the Management Information module to reallocate profit and loss.
However, additional features have been added to this application to allow for more complex allocation
to be carried out if required, and the underlying way in which the selection specified is different.
Each record on this file represents a rule, which will be used to check various types of profit and loss
entries, and produce a reallocation entry where appropriate. The types of entry that will be checked
are defined on the CATEGORY and MI.CATEG.GROUP tables.
The definition of each rule is specified using the MI.SELECTION mechanism.

The netting process is identical to that used in the other applications which produce records on the
MI.AUTO.ENTRY file- i.e. via the MI.NETTING.PARAMS application. Refer to details on this file
for a fuller explanation.
The specification of the allocation amount is set as a series of bands and a related percentage for
each band. The final band (that is all of the P & L entry not in the bands previously specified) may be
specified using the keyword REST.
e.g. There may be a requirement that each Department / Account Officer keep’s the first $100 dollars
from any profit they earn, and after that keeps half this profit. Hence two bands would be set, the first
BAND.AMOUNT set to 100 and the associated BAND.PERCENT set to zero, and the second
BAND.AMOUNT set to REST and the band percent set to 50.
MI.PL.ALLOCATION.2 Screen
MI.AUTO.MAPPING
This application is used as a generic interface to allow the generation of records on the
MI.AUTO.ENTRY file - P & L entries for use only within the MI module - to be generated from any
file.
At present the source files MI.STAT and MI.COF.ENTRIES are used to allow the information on
these files to be added to MI databases.
The information held on these records is used to build the MI.AUTO.ENTRY records, and the build
of the records from each source file is controlled via the application MI.AUTO.GEN.

The key to this file is the name of the source file to which it relates, and the record consists of a series
mapping fields.
A mapping field may contain literal values, names of fields on the underlying file, or decisions for using
one of two fields on the underlying file.
1. Literal value enclosed in double quotes. Data may only be entered in the first multi-value.
2. Name of field on underlying file. Data may only be entered in the first multi-value.
3. Conditional statement of the form:
• Multivalue 1 - IF AAA OPERATOR "VALUE"
• Multivalue 2 – BBB
• Multivalue 3 - CCC
If the condition is true then field BBB will be used otherwise field CCC is selected.
AAA, BBB, CCC are fields on the underlying file.
OPERATOR is one of the standard operands EQ, LE, LT, GE, GT, NE.
VALUE is a literal value enclosed in double quotes.
4. Conditional statement of the form:
• Multivalue 1 - IF SIGN EQ "VALUE"
• Multivalue 2 – BBB
• Multivalue 3 - CCC
This form is used for selecting a debit/credit field.

SIGN is the word SIGN (not in quotes).
VALUE is "CR" or "DR"
BBB & CCC are fields on the underlying file.
In addition to the mapping information, details of the netting to be used for this source file, the date on
which records for this source file were last created, and the selection of records to be used (either the
name of a routine or a select statement) are held on this file.

MI.AUTO.MAPPING used as a generic interface to allow the generation of records on the

MI.AUTO.ENTRY file

MI.STAT.TYPE
Records on this file are referenced from the MI.STAT.DEFINITION file and are used to hold details
of the cost to be assigned, which profit centres to use and which transaction / category codes should
be used.
When an outstanding item is analysed, it is assigned a MI.STAT.TYPE according to the

MI.SELECTION record, which it matched. The corresponding MI.STAT record is populated with
information held on this file.
MI.STAT.TYPE Input Record
MI.STAT.DEFINITION
This application is used to define processes, which can run on any file and will produce MI.STAT
records, which in turn can be used to create MI.AUTO.ENTRY records to record the P & L
information within MI databases.
Each record defines one process that will run on the specified file. Each record is examined, and if a
match is found to the MI.SELECTION records, the MI.STAT.TYPE is assigned and a record on the
MI.STAT file is created. When records on this file are reversed, the MI.STAT records, which were
produced by this process, are removed from the MI.STAT file.

MI.STAT.DEFINITION screen used to define process which can run on any
Example of a MI.STAT.DEFINTION record for allocating costs on FOREX transactions; the cost on
a Bulk FOREX transaction would be equally divided and allocated to Customers of the Client Deals
referring to the Bulk deal.

Example of MI.STAT.DEFINITION Record for FOREX cost allocation
The MI.SELECTION record attached to the above, selects all FOREX Deals including Bulk deals,
but omits Client deals linked to Bulk Deals, since the cost of a Bulk deal is allocated among the
Customers of its Client deals.
Example of MI.SELECTION Record for FOREX cost allocation
The MI.STAT.TYPE record for the above allocation example specifies that cost should be equally
divided and allocated to each customer (Field: SHARE.MULTI.CUST), in case there are multiple
customers for a transaction.

Example of MI.STAT.TYPE Record for FOREX cost allocation
This functionality can also be applied to Bulk Trades held in the SEC.TRADE application.
Example of MI.STAT.TYPE record for SECTRADE cost allocation

Transaction Files
MI.ENTRY - Internal postings for management information
The new MI.ENTRY file will hold profit and loss movements for internal use within the Management
Information system. These entries will be used for movements that only need to be shown on the MI
reporting and should not affect the real accounting, for example the reallocation of costs between
departments.
They are similar in structure to the accounting P&L movements (category entries) held on the
CATEG.ENTRY file. They may be associated with customers and/or product types if required, in
which case the detail associated with either the product or customer will be used to more accurately
allocate the entry to the Management Information reports, however only a department/account officer
code is a mandatory requirement.
There is no necessity for MI entries to balance and entries may be reversed, however the impact of
the reversal will only be realised if the MI system is rebuilt.

MI.ENTRY screen for internal postings for management information
Build Control Files

REBUILD.BAL.MVMT
This application enables the BALANCE.MOVEMENT file (which contains average balances and
other statistical information about accounts and contracts) to be built or rebuilt on-line. The basic build
is a three-stage process:
1. Populate BALANCE.MOVEMENT with historical data from.

2. Calculate average balances.
3. Evaluate refinancing rates.

The process normally updates BALANCE.MOVEMENT with all changes since it was last run (the
run date being held on the BAL.MVMT.BVAL table). However a rebuild from an earlier date may be
forced if this is required and this may be rebuilt for accounts, contracts, or both. It is achieved by;
specifying a rebuild date and running extra steps for accounts, contracts, or both.
All the steps in the build/rebuild process may be run at one time by verifying a
REBUILD.BAL.MVMT record with all steps set to Y, or steps may be run separately if required.
Rebuild Balance Movement Screen
MI.BUILD.DATABASE
This application controls the building and rebuilding of MI databases. Records can either be input
here and verified, in which case the build or rebuild action will be performed immediately when
MI.BUILD.DB is run as a service, or input here and referenced by the overnight batch in which case
the build or rebuild action will be performed automatically by the appropriate part of the batch.
The normal build of an MI database will simply build up to today from the last time the database was
built. This is the default type of build and will occur automatically if no rebuild dates are entered.
Sometimes it may be necessary to rebuild a database, i.e. to replace information already in the
database. This may be required in order to refresh adjusted average balances to take account of
back-valued transactions, to rebuild a database using modified MI parameters, etc.

Rebuilding requires the specification of a starting date (called the REBUILD.FR.DATE). An ending
date, REBUILD.TO.DATE, can also be input. This may be useful if the database is large and a full
rebuild will take an unacceptably long time. In these circumstances the database can be built in
sections.
The system allows builds and rebuilds to be performed for all source files or only for selected source
files. For this purpose the source files are divided into three types:
• BAL.MVMT - Balance Movement records

• ENTRIES - Profit and Loss entries from CATEG.ENTRY, MI.ENTRY and MI.AUTO.ENTRY
• BUDGET - Management Information BUDGETS
When combined with the ability to rebuild for a selected period, gives a range of options when
rebuilding a large database.
If the building of database is being performed within the overnight run then it must be placed in the
start-of-day stage or post start-of-day stage. This is to ensure that all entries are included over a split
month end. The BATCH.STAGE field on the BATCH record beginning with D, e.g. D930, identifies
the start-of-day stage. The post start-of-day stage will ensure that the MI processing does not
increase the length of the overnight critical path.
MI.BUILD.DATABASE input screen

MI.BUILD.STAT
This application is used to control the running of the analysis processes defined in the
MI.STAT.DEFINITION file to produce MI.STAT records, and records on this file are referenced
during the Close of Business to control the building of records during the Close of Business
processing.
When a process is run it will add records to the MI.STAT file unless a rebuild date is specified.
Hence, if the same process is run twice in the same month, two MI.STAT records will be created for
each record on the underlying file that matches the process.
When a rebuild date is specified, each record on the MI.STAT file, which was created on or before
the rebuild date, will be removed.
It is therefore recommended that at the end of each month, or period for which the MI.STAT records
are to be used, each process be rebuilt for that month only.
This process can be run either during COB or on-line by Verifying the SYSTEM record and running
BUILD.UOF.ENTRIES as a service.
MI.BUILD.STAT Input Record
MI.BUILD.COF.ENTRIES
This application is used to control the generation of cost of funds entries on the MI.COF.ENTRIES
file. These entries are produced from the BALANCE.MOVEMENT records themselves, using the

information defined on the MI.PARAMETER file. This process can be run either during COB or on-
line by Verifying the SYSTEM record and running BUILD.COF.ENTRIES as a service
MI.BUILD.COF.ENTRIES Input Record
MI.AUTO.GEN
This application is used to control the generation of MI.AUTO.ENTRY records, which are not
produced by the P & L allocation routines.
This application references records on the MI.AUTO.MAPPING file.

MI.AUTO.GEN Input Record
Batch Processes
The MI batch jobs perform the following functions:
• EOD.SYSTEM.END.OF.DAY.5The job EOD.BAL.MOVEMENT.BVAL captures back-valued

entries for later inclusion in the build of the
BALANCE.MOVEMENT file
• MI.BUILD.PLENTRIES This job performs the Profit and Loss allocation during the end of day
• MI.BUILD.DATABASE Build MI Database
• MI.PURGE This process removes records from the MI fields which are older than
the retention period specified on the MI.PARAMETER
• MI.ONLINE This process builds the MI.STAT, MI.COF.ENTRIES and creates
the MI.AUTO.ENTRY records
If the parameter field BUILD.BD.BALANCES is set to YES in MI.PARAMETER, the field

BK.BALANCE on ACCT.ACTIVITY will be updated.
The other jobs may be run at any time or not at all if the building of MI information is to be done on an
ad-hoc basis.

Building Balance Movement

The build or rebuild of the balance movement file is performed by the following jobs:
Frequencies
Job Description Mandatory Recommended
EOD.BAL.MVMT.BVAL This job runs in the end of day batch Daily
and ensures that all today’s business
will be correctly reflected in the next
rebuild of BALANCE.MOVEMENT
POPULATE.BAL.MVMT Populates BALANCE.MOVEMENT Daily
with contract and account activity.
Maybe run during the T24
overnight batch or adhoc using
REBUILD.BAL.MVMT
CALC.AVG.BAL.MVMT Calculates average balances on Monthly
BALANCE.MOVEMENT. May be
run during the T24 overnight
batch or adhoc using
REBUILD.BAL.MVMT
PURGE.BAL.MVMT This monthly job drops records Monthly
from BALANCE.MOVEMENT that
exceed the retention period
specified on MI.DATES. It should
normally be run monthly
Balance Movement Jobs
For more information on these jobs see the section on average balance files and processes.
Building Profit and Loss Entries
The BATCH process MI.BUILD.PL.ENTRIES performs the following job:

MI.PL.ALLOCATE This job performs the Profit and Loss allocation during the end of day, using
the parameter defined on the file MI.PL.ALLOCATION and
MI.PL.ALLOCATION.2 and will run the allocation such that the records are
up to date.
The BATCH process MI.ONLINE performs the following jobs:

MI.EOD.BUILD.STAT The building of MI.STAT records during the close of business process from
the processes defined on the MI.STAT.DEFINITION file is performed by
this job. Records on the MI.BUILD.STAT file are referenced in the DATA
fields and the build processes defined there are performed.
MI.EOD.BUILD.COF The building of MI.COF.ENTRIES records during the close of business
process, using the information on the BALANCE.MOVEMENT file and the

MI.PARAMETER file, I s performed by this job. Records on the

MI.BUILD.COF.ENTRIES file are referenced in the DATA fields, and the
build processes defined there are run.
MI.EOD.BUILD.PL This job performs the creation of MI.AUTO.ENTRY records from the
MI.STAT and MI.COF.ENTRIES files, using the data specified in the DATA
fields which reference records on the MI.AUTO.GEN file
Building MI databases
The MI databases are built and rebuilt by the job MI.EOD.BUILD.DATABASE, with DATA field set
with corresponding MI.BUILD.DATABASE record IDs’ (only those MI database will be built or
rebuilt). This can be run either by the overnight batch or by verifying records on the
MI.BUILD.DATABASE application and running MI.BUILD.DB as a service.
When run during the automated overnight batch, job will bring the specified databases up to date.
When run from MI.BUILD.DATABASE, the system will accept the input of rebuild dates, which can
be used to force a rebuild. This may be necessary if parameters have been modified since the last
build.
Purging
The information contained on the MI files, are subject to a periodic purge. The period for which data
within the MI application is retained is defined on the MI.PARAMETER file. During the purge
process the following files are examined:
MI.ENTRY
MI.AUTO.ENTRY
MI.STAT
MI.COF.ENTRIES
Database files
Any records which are older than the retention period allows are removed from the file and the
associated cross reference files where appropriate.
Live Files
BALANCE.MOVEMENT
This system maintained file holds account and contract information such as average balances and
balance history by month. It is keyed on the contract or account id and the month. The information
maintained is:

• The daily balance history.

• The number of transactions and transaction amount in the month by transaction code.
• Refinancing rates where specified.
• Average debit, credit and net balances. Averages are calculated in two ways - using the
interest basis of the contract or account and arithmetically.
• Number of days at which the account or contract was in debit, credit, or zero.
• In addition to the above for Accounts, if the parameter BUILD.BD.BALANCES is set to YES in
MI.PARAMETER, then the file holds daily balance information and average balances by
Booking Date or the date of the earliest Post Closing Database updated in case of entries with
an Accounting Date
All information except Booking date balances and averages, transaction and rate history is held in
three ways:
• Original - A snapshot of the value at the end of the period

• Adjusted - The value taking account of back-valuations made before the period closing date
• Post-Closing - The value taking account of back-valuations made after the period closing
date.
A work file, BAL.MVMT.BVAL, is populated each night from the STMT.ENTRY and
RE.CONSOL.SPEC.ENTRY files, for the entries raised during the day, including the effect of back
values.
If the parameter BUILD.BD.BALANCES is set to YES in MI.PARAMETER, another work file

BOOK.DATED.BALANCE is populated each night with the credit and debit movements by booking
date from ACCT.ENT.TODAY, for account entries raised during the day without an
ACCOUNTING.DATE. Movements for accounting entries with an ACCOUNTING.DATE are updated to
the file when the PC.UPDATE.REQUEST process updates the Post Closing Database.
The above-referred processes allow the population of movements and the calculation of averages to
be performed on BALANCE.MOVEMENT file whenever required and does not need to run during the
Close of Business.
The number of months that, information stored by will be controlled by the parameter file.

View Balance Movement File


Balance Movement Parameter File
Additional Cost of Funds

ADD.COF.TYPE ID of the file MI.COF.TYPE representing the additional cost of
funds type
ADD.COF.RATE.DR Additional cost of funds funding rate for debit balances
ADD.COF.RATE.CR Additional cost of funds funding rate for credit balances
ADD.COF.DEPT Funding Department for the Additional cost of funds

Book dated Balances (only for Accounts)

OPEN.BD.BALANCE Opening Book dated balance at start of month
CLOSE.BD.BALANCE Closing Book dated balance at end of month
BOOKING.DATE Booking Date/Date of earliest Post Closing database updated
BOOK.DR.MVMT Total debit movements on the date
BOOK.CR.MVMT Total credit movements on the date
BOOK.BALANCE Book dated balance on the date
BK.CR.DAYS The number of days the book dated balance was in credit
BK.CR.AVG.BAL The average book dated credit balances
BK.CR.AVG.BAL.MTH The average book dated credit balances including nil balances
BK.DR.DAYS The number of days the book dated balance was in debit
BK.DR.AVG.BAL The average book dated debit balances
BK.DR.AVG.BAL.MTH Te average book dated debit balances including nil balances
BK.ZERO.DAYS The number of days the book dated balance was nil
BK.AVG.BALANCE The average book dated balance (interest day basis)
BK.AVG.BAL.CAL The average book dated balance (calendar day basis)
BOOK.DATED.BALANCE
This system-generated file holds records for each account-month combination. This file records the
balances and averages by Booking Date and the information in the file is used to build the Booking
date balances and averages for Accounts in BALANCE.MOVEMENT file. In case of entries with an
Accounting Date, the date of the earliest Post Closing Database updated would be the basis for
recording the movements.
The file is built first time when the parameter BUILD.BD.BALANCES is set to YES in
MI.PARAMETER. After that the file is updated from ACCT.ENT.TODAY for entries without an
Accounting Date by the Batch job BOOK.DATED.BALANCE.BUILD in the Batch
MI.BUILD.BAL.MVMT. Hence this Batch job must be compulsorily run every day if the Book dated
balances are to be built in the BALANCE.MOVEMENT records of Accounts.
For entries with an Accounting Date, the file would be updated when the PC.UPDATE.REQUEST
application is run to update the Post Closing Database.

Book Dated Balance File View
BAL.MVMT.BVAL
This system-generated file holds records for each contract and account. The records contain dates
that are used to trigger BALANCE.MOVEMENT processing. Two dates are held. The first is the
date of the earliest back valued movement across the contract or account. This date is used to drive
the transfer of information from the contract or account file in to the BALANCE.MOVEMENT file.
The second date is the date from which average balances need to be calculated.
If there is a back valued movement across a contract or account then both dates are set to the back
value date. This means that all history from this point on is recopied to BALANCE.MOVEMENT
and that all average balances from this point on are recalculated.
MI.DATA.XXXXX - The management information database

This file stores the consolidated MI data. It is constructed based on the conditions in
MI.DB.DEFINITION and provides the base data from which reports are constructed.
The file is created automatically when the MI.DB.DEFINITION is authorised. The name of the file
begins MI.DATA and is completed with the database id on MI.DB.DEFINITION. For example the
GMPR database would be called “MI.DATA.GMPR”. A STANDARD.SELECTION record is also
generated.

All field definitions, except company and database id, are created automatically and their names
reflect the field content. In this context it is useful to consider the fields on MI.DATA in three
categories: line numbers, consolidation components, and columns.
Line numbers form part of the key. The field name will be taken from the id of the line definition held
on the MI.LINE table. Consequently the field name will consist of two components - the report type
and the line number. For example if this record is to appear in line 25 of the detailed customer
profitability report then the field might be ‘DCPR.0025’.
Consolidation components also form part of the key. Their field name will be taken from the contents
of the CONSOLIDATE.BY field on the MI.DB.DEFINITION record. Thus if consolidation is
required by customer id then the field name might be ‘customer’.
Columns are part of the record detail and are described below.
The key to the file is based on the following components:
• COMPANY - Company to which the data pertains

• DATABASE.ID - The database id from MI.DB.DEFINISTION eg CPR
• LINE - The line number determined by MI.LINE eg 0001
• YEAR.MONTH - The year and month of this information
• Report type line - The line number in the report type (See above)
• Component 1 - The value of the first consolidation component (see above)
• Component 2 - The value of the second component (see above)
The data stored in the file will be generated automatically depending on the specifications made in
MI.COLUMN. The names of the fields will be as specified in MI.COLUMN with the VALUE.TYPE
extension. The description will be the short description from the MI.COLUMN record plus the
VALUE.TYPE extension. For example, if MI.COLUMNS specified that we are to hold the average
balance, interest earned and commission earned and all are to be held month to date and year to date,
then the system would generate fields as follows:
• AVG.BAL.MTD - Average balance MTD

• AVG.BAL.YTD - Average balance YTD
• INT.INC.MTD - Interest income MTD
• INT.INC.YTD - Interest income YTD
• COMMIS.MTD - Commission income MTD
• COMMIS.YTD - Commission income YTD

MI.AUTO.ENTRY
This file contains those entries raised by the Profit and Loss allocation processes and from the generic
MI.AUTO.ENTRY generator MI.AUTO.MAPPING. This live file is then incorporated at build time
into MI databases.
MI.BUDGET - The management information budget file

This table stores the budget figures. User input is not permitted, all budgets being specified on the
MI.BUDGET.LINE application.
MI.STAT
This file contains those entries created by the analysis processes defined in the file
MI.STAT.DEFINITION and executed via the MI.BUILD.STAT application, which are processed
by the application MI.AUTO.MAPPING to produce MI.AUTO.ENTRY records.
MI.COF.ENTRIES
This file contains those entries raised by the process MI.BUILD.COF.ENTRIES, which is used to
create debit and credit cost of funds entries from record on the BALANCE.MOVEMENT file using
the parameters set on the MI.PARAMETER record.
Cross Reference Files

The following files are used within the MI module to allow the related files to be selected and
processed more efficiently. Each record on these files consists of up to 200 keys, which point to the
related file. Where more than 200 records would fall into each cross-reference file, the
SEQUENCE.NO of the record is incremented.
MI.AUTO.ENTRY.MONTH
This file is related to the MI.AUTO.ENTRY file. The id to MI.AUTO.ENTRY.MONTH is

GEN.SYS.ID * YR.MONTH * SEQUENCE.NO
The first part of the key is composed of the GEN.SYS.ID of the MI.AUTO.ENTRY records in question.
The second is the year and month of the value date of the record.
MI.STAT.XREF
This file is related to MI.STAT. The id to the MIS.STAT.XREF is

MI.STAT.DEFINITION.ID * DATE.CREATED * SEQUENCE.NO

The first part of the key is set to the key of the MI.STAT.DEFINITION record, which created the
records, and the second part of the key is set to the date on which the records were created.
MI.COF.ENTRIES.XREF
The MI.COF.ENTRIES XREF is related to MI.COF.ENTRIES. The id to this file is;

FILE.TYPE * YR.MONTH * SEQUENCE.NO
The first part of the key, the FILE.TYPE, is set to either ACCOUNT or CONTRACT and is dependant
on the BALANCE.MOVEMENT record, which created the entry. The second part of the key is the
year and month taken from the BALANCE.MOVEMENT records.
CATEG.PC.MONTH
The CATEG.PC.MONTH is related to the CATEG.ENTRY file, the id to this file is;
YR.MONTH
The records in the file are generated if the parameter BUILD.PL.ENTRIES is set to ACCOUNTING
in the file MI.PARAMETER to consolidate P&L entries by Accounting Date. This file contains IDs of
CATEG.ENTRY records with an Accounting Date, which have been updated to Post Closing
Database. The file is updated when the PC.UPDATE.REQUEST application is run. The Ids are listed
under the month equal to that of the earliest Post Closing Database updated. This file is used when MI
database are built to consolidate the P&L entries by Accounting date; CATEG.ENTRY records
without an Accounting Date are consolidated by Booking date using the cross reference file
CATEG.MONTH.
Routines and programs

MI.CALC.INT.RATE - Calculate interest rate
This routine may be called from I type fields on STANDARD.SELECTION. It is used to calculate
the interest rate from a given principal and accrual amount.
Its recommended use is on MI databases (MI.DATA.XXXX files) to calculate the interest rate from
the average balance (source from BALANCE.MOVEMENT) and the interest accrual earned (source
from CATEG.ENTRY). It will normally be passed both amounts in original currency to avoid the
effect of foreign exchange rate changes during the period.
It is passed:

• Principal amount
• Interest amount
• Database id
• Period on that database
• Interest basis
And it returns
• Interest rate
An example of its use in the standard selection record for a Management Information database
(MI.DATA.XXXX) is as follows:
STANDARD.SELECTION MI.DATA.XXXX
Setup
Installation Notes
Parameterised installation
The Management Information application is highly parameterised. Careful and considered installation
will pay great rewards in terms of long-term flexibility of the system. However in order to begin the
process of understanding MI quickly, a small range of example parameters are provided to produce
the GMPR (departmental performance) enquiry.
The majority of the parameters can be authorised without modification, however the MI.SELECTION
parameters reference various existing system values such as category codes. These should be
reviewed to ensure that the definition on MI.SELECTION matches the definition already implicit in
your system set-up.

The steps for installing the example are:
1. Install the MI Application
Use RELEASE to install the Management Information module. See the System Administration guide
for further information. Authorise the following records:
STANDARD.SELECTION
HELPTEXT
HELPTEXT.MENU
All further steps can be performed using the Management Information menu, which can be accessed
by entering MI.MENU at the Awaiting Application prompt.
2. Review BALANCE.MOVEMENT sizing
At this point you should review the file sizing of the BALANCE.MOVEMENT file to ensure it is
adequate. The file sizes should be reviewed again upon the completion of the exercise to ensure they
are correct.
3. Input the SYSTEM record on MI.PARAMETER.
Recommended retention period is 13 months. The only other mandatory field is the start day of the
week - usually set to Monday.
You could consider inputting at least one interest key at this stage. This will be used by the system to
set a default ‘cost of funds’ refinancing rate on all accounts and transactions.
If the CATEG.ENTRY records are to be consolidated in MI Databases by Accounting Date (the
default is by Booking Date), set up the parameter BUILD.PL.ENTRIES to ACCOUNTING. When this
parameter is updated, ensure that no Post Closing Database is kept in an open status (fields
PERIOD.STATUS and COMP.STATUS in the application PC.PERIOD should be CLOSED). Further,
it should be ensured that the parameter is switched to YES only at Start of Day, before any
transactions are input into . The switching of this parameter would consolidate by Accounting Date,
only those, post closing CATEG.ENTRY’S, input after that. Since the consolidation of MI Databases
would be affected whenever Post Closing databases are updated for CATEG.ENTRY’S with an
Accounting Date by PC.UPDATE.REQUEST application, ensure that MI Databases are rebuilt after
the PC databases are updated.
4. Activate BALANCE.MOVEMENT

Install the BALANCE.MOVEMENT (average balances) mechanism. See the separate section in
this guide for further information. If you have not input a refinancing rate on MI.PARAMETER in the
earlier step then you do not need to rebuild refinancing rates.
5. Review and authorise the MI.SELECTION records
These will require careful review because they define products and analysis categories to MI. These
definitions are based upon information already stored in your system (for example category codes)
and thus will have to be adapted to your existing set-up.
6. Authorise the remaining example records.
They are:
MI.REPORT.TYPE
MI.LINE
MI.COLUMN
MI.DB.DEFINITION
ENQUIRY
7. Perform the first build of the database

Verifying the record REBUILD.GMPR in MI.BUILD.DATABASE does this. This activity can take
some time so we recommend you begin by just building the last complete month. Do this by setting
the REBUILD.FR.DATE to the first day of the previous month and the REBUILD.TO.DATE to the last
day of the previous month.
The record should look like this:

Perform the first build of the database
The GMPR database is now available and may be enquired upon by running the enquiry GMPR (ENQ
GMPR at the awaiting application prompt)
Installing BALANCE MOVEMENT (average balances)

The installation of average balances consists of the following steps:
• Define the length of average balance history that the system is required to keep;
• Specify in MI.PARAMETER which types of average balances (ADJ, POST, VALUE) need to be
built in BALANCE.MOVEMENT
• Specify in MI.PARAMETER for which applications BALANCE.MOVEMENT related data
needs to be maintained
• Specify in SC.PARAMETER whether BALANCE.MOVEMENT related data needs to be
maintained for Security transactions in Customer Portfolios
• Setting the parameter BUILD.BD.BALANCES in MI.PARAMETER to YES if book-dated
average balances are required. This would build on-line the opening book dated balances for all
accounts for the month in the file BOOK.DATED.BALANCE. When this parameter is switched
to YES, it should be ensured that no Post Closing Database is kept in an open status (fields
PERIOD.STATUS and COMP.STATUS in the application PC.PERIOD should be CLOSED).
Further, it should be ensured that the parameter is switched to YES only at Start of Day, before
any transactions are input into T24. The switching of this parameter would consolidate by
Accounting Date only those Post Closing entries input after that. Since the Booking date related

balances and averages in BALANCE.MOVEMENT would be affected whenever Post Closing

databases are updated by PC.UPDATE.REQUEST application, it should be ensured that
BALANCE.MOVEMENT records are rebuilt after the PC databases are updated.
• Optionally performing a one-time build from history;
• Establish batch jobs that will automatically keep the average balances up to date.
MI.DATES - Defining the parameter

Parameter records need to be set up for each company, which has the MI module, installed. The
following values are recommended:
UPDATE.MVMTS Y
NO.MONTHS 13
DEFAULT.CLOSE.YEAR 10
DEFAULT.CLOSE.DAY 4
A typical record might look like the following:
Define MI.DATES Record
REBUILD.BAL.MVMT - Defining the build jobs

For most purposes a single record on this file can be used to control the average balance building
process. All build steps should be set to Y to ensure a full build. The rebuild date should be set to
sufficiently far in the past for all reporting purposes. The beginning of the current year might be

chosen. The BALANCE.MOVEMENT file may be rebuilt again at a later date if required so
decisions made at this point may be changed later.
A suitable record might be like the following:
Rebuild Balance Movement Screen
Performing the one-time rebuild from history

The average balance mechanism will automatically ‘catch up’ whenever it is run. This means that the
first time the average balance build process is run it will take a long time. For this reason you may like
to consider running the first rebuild manually, perhaps on a weekend. Afterwards the normal batch
process can be used to keep the average balances up to date.
To run the rebuild manually simply verify the REBUILD.BAL.MVMT record already created.
If your system is very active and you suspect that the rebuild will take an exceptionally long time, you
could consider splitting the job into separate manual stages, one for each of the build options on
REBUILD.BAL.MVMT.
The ‘extract refinancing rates’ rebuild depends on the presence of the MI.PARAMETER record and
the cost of funds rates input there. If you have not done this yet, then running the extracting
refinancing rates is not necessary.

Batch jobs to automatically update Balance Movement
The batch jobs are contained on the record MI.BUILD.BAL.MVMT. This record should be
reviewed and amended as necessary. The records as delivered have set to run AD-HOC. You
should consider changing the populate jobs and calculate jobs to daily or monthly, depending on the
frequency you intend to update Management Information databases.
See the section on batch jobs in this guide for further details.
Technical Overview
This section contains information of a technical nature concerning the Management Information
module. Its purpose is to show how the MI module fits together and how best to set up certain files for
performance benefits.
The Management Information module processes incoming information from SOURCE FILES,
controlled by BUILD.FILES and, using the parameters defined on the PARAMETER FILES,
produces DATABASE FILES. Each of these distinct types of file and associated routines will be
discussed.
There is a brief section on the setting up of the selection records with a view to the performance of the
matching routine, and another brief section on the format of MI.BUDGET.LINE records.
The routines, which have been provided as part of the module for, use within ENQUIRY or as an I
descriptor are detailed in the section on ENQUIRY ROUTINES.
Finally, an overview of the MI module is shown, and a breakdown of the sub systems within the
module is then detailed.
PARAMETER SOURCE DATABASE BUILD

Main BALANCE.MOVEMENT/
• MI.PARAMETER • MI.DB.DEFINITION MI.AUTO.GEN
Files BAL.MVMT.WRK
• MI.LINE CATEG.ENTRY MI.DATA….. MI.BUILD.COF.ENTRIES
• MI.COLUMN MI.ENTRY MI.BUILD.STAT
MI.DATES MI.AUTO.ENTRY REBUILD.BAL.MVMT
MI.AUTO.MAPPING MI.BUDGET
MI.UNIT.COST MI.COF.ENTRIES
MI.STAT
Files MI.REPORT.TYPE BAL.MVMT.BVAL MI.BUILD.DATABASE

• MI.SELETION MI.BUDGET.CONTROL
MI.BUDGET.CONTROL$RUN
MI.BUDGET.LINE
MI.BUDGET.TYPE
MI.PL.ALLOCATION
• MI.PL.ALLOCATION.2
• MI.STAT.DEFINITION
MI.STAT.TYPE
MI.DETERMINE.INT.SEL MI.BUILD.BAL.MVMT.
Routines DETERMINE INT.BASIS EOD.BAL.MOVEMENT
.PRIORITY ENTRIES
MI.PURGE EOD.MI.CHECK.PL MI.CREATEFILE MI.AUTO.GEN$RUN
MI.BUILD.COF.ENTRIES$
MI.DETERMINE.MATCH EOD.MI.PL.ALLOCATE MI.DB.CLEAR
RUN
MI.EVALUNIT.COST EOD.MI.PL.ALLOCATE.2 MI.EOD.BUILD.DATEBASE MI.BUILD.STAT$RUN
MI.BUDGET.FOR.ENRI MI.FIELD.JOIN MI.EOD.BAUIL.COF
MI.BUDGET.SORT MI.POPULATE.DATABASE MI.EOD.BUILD.DATABASE
MI.CHECK.BALMVMT MI.PURGE MI.EOD.BUILD.PL
MI.CHECK.BUDGET MI.BUILD.DATABASE$RUN MI.EOD.BUILD.STAT
MI.CHECK.PL POPULATE.BALMVMT
MI.CREATE.BUDGET POPULATE.BALMVMT.BVAL
MI.DOWNLOAD.BUDGET CALC.AVG.BAL.MVMT
MI.ENTRY.DEFAULT MI.PROCESS.REFINANCE
MI.ENTRY.OVERRIDE MI.PROCESS.RATEDATE
MI.PROCESS.NETTING
MI.PURGE
MI.SELECT.COF
MI.SELECT.FILES
MI.SELECT.STAT
MI.UPLOAD.BUDGET
PURGE.BAL.MVMT
MI.CATEG.GROUP
MI.NETTING.PARAMS
MI.ENTRY.TYPE
Overview MI Module

Parameter Files
MI.LINE
Key: MI.REPORT.TYPE LINE.NO

Where LINE.NO is four numeric characters
Associated Files
MI.REPORT.TYPE
Key: Six alpha characters

It specifies unique selection and group descriptions.
Unique selection should be habitually used.
Associated Routines
DETERMINE.INT.SEL.PRIORITY
This routine determines the internal selection priority of the MI.LINE records.
The unallocated line 9999 will always have an internal selection priority of 1111111.
MI.PARAMETER
MI.PARAMETER holds the parameters for the refinancing information to be added to the
BALANCE.MOVEMENT file, which are specified using the MI.SELECTION method. Further
refinancing parameters for MI.COF.ENTRIES generation are also held here.
Also holds which day is considered to be the start of week (used for weekly databases, otherwise not
used).
Specifies the retention of MI data records and applies to MI.ENTRY, MI.AUTO.ENTRY,

MI.BUDGET and the MI.DATA records. This is used for the purge job MI.PURGE.
MI.COLUMN
MI.COLUMN is used to define the contents of the database, the key ending up as the field name on
the database file. It specifies source fields for each of the source files. Selection operand for the
selections (AND / OR)

The @id to the records, are 12 Alphanumeric characters
MI.DATES
MI.DATES holds a flag to determine if the BALANCE.MOVEMENT file is required to be updated,

and if so for how many months the information on the BALANCE.MOVEMENT file is to be
maintained. This is cleared out during the EOM process PURGE.BAL.MVMT.
In addition holds the information on month closing, which is updated by PURGE.BAL.MVMT and
POPULATE.BAL.MVMT.BVAL.
The @id to the record is the Company code.
MI.UNIT.COST
MI.UNIT.COST is used to define costs of events, in local currency, by date.
Associated Routines
MI.EVAL.UNIT.COST
MI.EVAL.UNIT.COST is used to evaluate a given MI.UNIT.COST record given a date.
MI.AUTO.MAPPING
Key: Source file

Acts as a mapping file to allow source files to produce records on the MI.AUTO.ENTRY file.
Currently only used for MI.STAT and MI.COF.ENTRIES.
Source Files
MI.BUDGET
The key to this file is

COMPANY, DATABASE, MI.DATE, REPORT.LINE, BUDGET.TYPE, consolidation components
Where:

REPORT.LINE is a valid record on the MI.LINE file and the report type is that of the database to
which the database pertains.
BUDGET.TYPE is a valid record on the MI.BUDGET.TYPE file.
Consolidation components are the consolidation components from the database.

Records on this file are produced by the MI.CREATE.BUDGET routine using the data the user has
specified on the corresponding MI.BUDGET.LINE records.
MI.BUDGET.CONTROL
This file produces the MI.BUDGET.LINE records, with a status of IHLD on the unauthorised file of
MI.BUDGET.LINE, from the parameters as specified on the MI.DB.DEFINITION record.
MI.BUDGET.LINE
This is the file from which MI.BUDGET records are produced. The main use of this file is to protect
the user from the need to enter a MI.BUDGET key for each area that a budget is required for.
Budgets are set one year at a time. If there is no amount in the set for a MI.BUDGET record when it
is created, then the record will not be created.
This file provides the ability to split annual amount over each period, and to upload and download a
MI.BUDGET.LINE record to a PC. See the diagram section for details on the layout of the
MI.BUDGET.LINE text records.
The @id of the file is

Company.Code_Database.id_Budget.Type_Year
MI.BUDGET.TYPE
This file is used to form part of the key of the MI.BUDGET.LINE records and is one of the
mandatory fields on the MI.BUDGET.CONTROL file.
MI.BUDGET.CONTROL$RUN
Called when the MI.BUDGET.CONTROL record is verified using the budgeting parameters set up
on the MI.DB.DEFINITION record(s), and produces a record with a status off HLD on the
unauthorised file of MI.BUDGET.LINE.
If the keyword ‘EXIST’ is found, then the BUDGET.FOR fields produced on the MI.BUDGET.LINE
records will be those which exist on the MI.DATA records.

MI.BUDGET.FOR.ENRI
This routine takes a list of BUDGET.FOR fields and a list of the related files and returns a list of
enrichments. If one of the elements of the BUDGET.FOR was not on the related file then an error is
returned. Hence this routine is also used to validate the BUDGET.FOR fields.
This routine is called from MI.BUDGET.CONTROL$RUN when creating the MI.BUDGET.LINE

records and from MI.BUDGET.LINE when validating the BUDGET.FOR fields.
MI.BUDGET.SORT
Called when the MI.BUDGET.LINE record is authorised with the SORT.BUDGET flag set to yes,
and sorts the MI.BUDGET.LINE record by BUDGET.FOR.
MI.CHECK.BUDGET
Checks the MI.BUDGET.LINE file for any records for the databases on the
MI.BUILD.DATABASE record, which have not created the MI.BUDGET records and calls the
MI.CREATE.BUDGET routine where applicable.
MI.CREATE.BUDGET
This takes an id of a MI.BUDGET.LINE record and creates (or removes) the appropriate records
from the MI.BUDGET file. This routine is called whenever the MI.BUDGET.LINE record is
authorised to remove those records from the MI.BUDGET file, which may have been created by the
previous authorised record.
This routine is called to create records from MI.CHECK.BUDGET and also from
MI.BUDGET.LINE when the user build facility is used.
MI.DOWNLOAD.BUDGET
This routine creates a text record under the path name as specified in the DOWN.LOAD.FILE field of
the MI.BUDGET.LINE record. For details of the format of the record refer to the diagram at the end
of this document.
MI.UPLOAD.BUDGET
This routine reads a text record from disk and converts it into a MI.BUDGET.LINE record, which is
stored, with a status of IHLD, on the unauthorised file. For details of the format of the record refer to
the diagram at the end of this document.

BALANCE.MOVEMENT
This file is produced by the routine MI.BUILD.BAL.MVMT.ENTRIES and consolidates

BALANCE.MOVEMENT records (which are monthly) into records which are relevant to the
frequency of the database. This is currently not working for daily and weekly frequencies.
The key to this file is

Account Number or Transaction reference ‘*’ Year and Month [‘*’ Currency]
e.g. 108*199601
And to BAL.MVMT.WRK is
Account Number or Transaction reference ‘*’ ‘P’ Period Number
E.G. 108*1996P01
BAL.MVMT.BVAL
This file is used to control the dates from which the various population jobs, which affect the
BALANCE.MOVEMENT file, are run.
PURGE.BAL.MVMT
Monthly job to purge BALANCE.MOVEMENT records using the retention period specified on the
MI.DATES record for each company.
DETERMINE.INT.BASIS
If the I descriptor for INTEREST.BASIS for a contract returns ‘RTN’ then this routine is called to
determine the INTEREST.BASIS.
At present this is only done for FX. The routine is passed a currency and a contract id and returns the
interest basis specified on the record for that currency. This routine is called from
POPULATE.BAL.MVMT.
EOD.BAL.MVMT.BVAL
This routine runs in the batch and processes daily movements across accounts and contracts and
updates the relevant fields on the BAL.MVMT.BVAL records.
MI.CHECK.BAL.MVMT
This routine is called when the database build is run and ensures that the BALANCE.MOVEMENT
file is up to date. If the database build is being run on line then the build will not continue if the

BALANCE.MOVEMENT file is not up to date. If the build is running in the batch, then it will
continue regardless.
CATEG.ENTRY
CATEG.ENTRY is a standard file; refer to main user guide for details.
MI.AUTO.ENTRY
Records on this file are produced by the Profit and Loss allocation process or via the
MI.AUTO.MAPPING application and have a key similar to the CATEG.ENTRY file.
MI.PL.ALLOCATION
The records on this file hold the details of the re allocation of P & L within the department hierarchy.
Details whether records are to be netted or not, and if so which type of netting is to be used. The key
to the file is the ID of the DAO record it pertains to
EOD.MI.CHECK.PL
This job is called in the batch as the process MI.PL.ALLOCATE. All this routine does is call
EOD.MI.PL.ALLOCATE with a null for the date.
EOD.MI.PL.ALLOCATE
This routine creates MI.AUTO.ENTRY record using the parameters set up on the
MI.PL.ALLOCATION file.
If a rebuild is needed, (specified as a rebuild date on the MI.BUILD.DATABASE record) then the
records on the MI.AUTO.ENTRY file are removed by the routine MI.SELECT.FILES.
Once the allocation is done, the routine MI.PROCESS.NETTING is called to handle the netting of
the MI.AUTO.ENTRY records and the updates of the file and the cross-reference file
MI.AUTO.ENTRY.XREF.
MI.SELECT.FILES
This routine is used in a variety of places within the MI module to select records on the
MI.AUTO.ENTRY, MI.STAT and MI.COF.ENTRIES files via the respective cross reference files.
This routine can also be called in delete mode, whereby the records on the file are removed and the
cross-reference files are kept in line.

MI.PL.ALLOCATION.2
This application is used as the advanced form of P & L allocation, using the MI.SELECTION
mechanism.
EOD.MI.PL.ALLOCATE.2
This routine is called from EOD.MI.PL.ALLOCATE and creates records on the MI.AUTO.ENTRY
file in a similar manner to the routine EOD.MI.PL.ALLOCATE, except the rules defined on the
MI.PL.ALLOCATION.2 table are used.
MI.NETTING.PARAMS
This application is used to define the fields, which will be used as the netting criteria when creating
records on the MI.AUTO.ENTRY file and is referenced from the routine MI.PROCESS.NETTING.
MI.PROCESS.NETTING
This routine is the only routine that creates records on the MI.AUTO.ENTRY file, and in doing so
updates the cross-reference file MI.AUTO.ENTRY.XREF. The netting process takes place in this
routine using the parameters defined in the MI.NETTING.PARAMS file.
MI.CHECK.PL
This routine is called when a database is being built on line and checks that the P & L allocation is up
to date if this is required for the database build. If it is not the user is prompted to run the P & L
allocation routine.
MI.ENTRY
The key is a 10-digit number, prefixed with MI to represent Management Information, in the following
format:
MI YY DDD 99999 where:
MI = Management Information
YY = Current Year
DDD = Julian Day
99999 = Sequence Number

E.g. MI9614300012
Records on this file are manual adjustments to P & L. These records only impact on the Management
Information module and do not appear elsewhere.
Associated Routines
MI.ENTRY.OVERRIDE
This routine processes a MI.ENTRY record for any necessary overrides (namely rate checking) and
processes the overrides accordingly.
MI.ENTRY.DEFAULT
This routine processes the defaulting of fields, including the currency amounts from each other.
MI.STAT
Records on this file are produced by the routine MI.BUILD.STAT$RUN and hold statistic
information. Each record on this file will produce two records on the MI.AUTO.ENTRY
MI.STAT.TYPE
This is used to hold information concerning the transaction codes, profit centres and P & L category to
be used for the MI.STAT.TYPE.
MI.STAT.DEFINITION
MI.STAT.DEFINITION defines the processes, which are run to produce the MI.STAT records.
When the record being processed matches the associated selections, a MI.STAT.TYPE is assigned.
MI.SELECT.STAT
This routine is used to select the MI.STAT file via the MI.SELECT.FILES routine.
MI.COF.ENTRIES
Records on this file are created from the routine MI.BUILD.COF.ENTRIES$RUN, and hold the
cost of funds, or refinancing information. Each record on this file will produce two records on the
MI.AUTO.ENTRY
One entry is present for each of the debit and credit refinancing entries where applicable. For

contracts there will usually be only one.
MI.SELECT.COF
This routine is used to select the MI.COF.ENTRIES file via the MI.SELECT.FILES routine.
Database File
File name: MI.DATA. MI.DB.DEFINITION
e.g. MI.DATA.GMPR
Key: Company_Database.Id_Mi.Date_Mi.Line_Consolidation.Components
This is the file, which is the result of the five source files and of the parameters. The main build
routine, MI.POPULATE.DATABASE, consolidates the information from the source files using the
various parameters set up in the parameter files. The main parameters are MI.LINE and
MI.COLUMN. For each database there is a record on the MI.DB.DEFINITION file which defines
which set of lines and which columns are to be used by the database;
MI.DB.DEFINITION
Key; Four alphanumeric characters
This is the main parameter file for the MI databases, and there is one record per database. The
record contains the following information;
• The selections for the database. These are MI.SELECTION records and are used to exclude
records from the database at the very highest level. As these selections will be evaluated for
every record it is important to ensure that the selections are in a sensible order - see the section
on MI.SELECTION.
• The frequency at which information will be gathered, and hence the size of the database periods.
This has nothing to do with the frequency at which the database build routine is run; it merely
determines the number of periods in a year.
• Consolidation components. When these are evaluated (at run time) they provide additional
components to the key for the MI.DATA records, and hence allow data to be held at differing
levels of detail
• An audit trail showing, for each period the database has been built for, the date up to and
including which data has been processed for each type of file.
• The report type for the database, and hence which MI.LINE records will be used when the
database is populated
• The columns, which are to be present on the database. These appear as fields on the final
MI.DATA records

• Budgeting information. The level at which budgets are to be held is defined at database level
along with the areas for which the budget is set. This information is used to create
MI.BUDGET.LINE records and hence MI.BUDGET records
Associated Files
All of the parameter files and the source files are used either directly or indirectly by the main
population routine, and hence the MI databases, as well as;
MI.BUILD.DATABASE
These records control the building of MI databases, whether on line or during the batch. On line,
verifying the records carries out the build. During the batch the records are referenced via the
BATCH records in the data fields.
These records control the type of build (whether for all file types or for individual file types) and
whether it is an incremental run (e.g. from the last time run) or a rebuild.
Associated Routines
MI.BUILD.BAL.MVMT.ENTRIES
This routine builds the BAL.MVMT.WRK file from the BALANCE.MOVEMENT file, consolidating
the average balances according to the frequency of the database being built. When this is done the
standard selection record for BAL.MVMT.WRK is copied from the current record for
BALANCE.MOVEMENT. The file is cleared by the main routine when it has finished.
MI.BUILD.DATABASE$RUN
This routine is called when a MI.BUILD.DATABASE record if verified and checks the prerequisite files
by calling MI.CHECK.PL, MI.CHECK.BUDGET and MI.CHECK.BAL.MVMT. If the records
are up to date then MI.POPULATE.DATABASE is called.
MI.CREATE.FILE
The file is for the MI.DATA records and is created by this routine, as well as the file control record,
the STANDARD.SELECTION record and the dictionary records.
The STANDARD.SELECTION records and the dictionary records are updated every time the file is
authorised.

MI.DB.CLEAR
MI.DB.CLEAR clears out the columns, which have a source field from one of the files being cleared
down. This is related to the type of file, which is being built;
Type of File Files
MI.BUDGET MI.BUDGET
BALANCE.MOVEMENT BALANCE.MOVEMENT
PL.ENTRIES CATEG.ENTRY
MI.ENTRY
MI.AUTO.ENTRY
MI.EOD.BUILD.DATABASE
This routine allows database builds to be run during the batch. The P & L allocation is run as a
separate job. If the BALANCE.MOVEMENT file is not up to date then a record is written to the
EXCEPTION.LOG.FILE.
The ids of the MI.BUILD.DATABASE records are taken from the data fields on the batch record.
The routine MI.CHECK.BUDGET is run for each build database id and then the main build routine
is run for each build routine.
MI.PURGE
This routine is run in the Close of Business and is used to remove MI.DATA, which is no longer
required. The retention period is specified on the MI.PARAMETER record ‘SYSTEM’ and from this
the MI.ENTRY and MI.AUTO.ENTRY files are purged of any records with a booking date before
the purge date.
Each database record is read and then the database files (MI.DATA) and the MI.BUDGET file are
purged of any records, which are before the purge period.
MI.POPULATE.DATABASE
Initialising
Open files.

Read MI parameter record.

Read MI.BUILD.DATABASE record.
Set the type of database build (full or which file type).
Set Frequency.
Check locking if non-monthly and lock it.
Clear cache.
Read all MI.SELECTION records into cache.
Set LCY details (number of decimals, interest basis).
Cache interest basis records.
Determine build period

Per file type being built, set:
Rebuild from date and period
Rebuild to date and period
Set up date list

Set up the currency cache date list (periods in build and period end dates).
Complete the interest basis cache by working out the number of days in each period of the
build for each interest basis.
Select Base Files - Select the records in the rebuild period.

Select CATEG.ENTRY via CATEG.MONTH.
Select BALANCE.MOVEMENT if monthly OR call MI.BUILD.BAL.MVMT.ENTRIES,
which creates the consolidated records and returns a list of ids.
Select MI.ENTRY and MI.AUTO.ENTRY.
Process database files

For each database;
Open the MI.DATA.FILE.
Clear out any records as per the build type.
Read the database record and LOCK it.
Cache the column records by database and hold a list of source files associated with
that column in a master column cache.
Set the rebuild date on the database by file type and write record, maintaining the
lock.
Budgets processed for each database.
Determine MI report

Update Internal selection priority => calls DETERMINE.INT.SEL.PRIORITY.

Cache the MI.LINE records by descending INT.SEL.PRIORITY.
Process Base Files

For each of the source files (not budgets!) read Standard Selection.
(Processed in the order CATEG, BM, MI.ENTRY, MI.AUTO.ENTRY).
Process Base Entries

Cache field names, numbers and types in alpha order.
Open dictionary for the file that is being processed.
Clear current dictionary cache.
Produce a list of columns, which we will process for the current source file.
The following processing is done for each record:

For each record in source file list:
Read the record.
Set entry currency and entry date.
Match MI database
Call MI.DETERMINE.MATCH with database level selection.
If matched then identify consolidation components.
If record matches at least one record then continue.
Determine MI line
Try and match the source record to the list of lines.
If matched at least one line then continue.
Update MI line
Determine entry period of the entry.
For each Database:
Read database record.
For Each column:
Match to column.
If matched, evaluate entry value and modify column value.
Write database record.

Build Files
These files are used to control the creation of the source file records. Each build file may have one or
more associated routines.
REBUILD.BAL.MVMT
This file is used to run the various population jobs, which affect the BALANCE.MOVEMENT file
whilst on line. The jobs are run in descending order if the flag is set, e.g. rebuild dates for accounts,
then contracts, then population, then calculation and finally refinance rate extraction.
POPULATE.BAL.MVMT.BVAL
This rebuild job modifies the build dates on the BAL.MVMT.BVAL file and processes both accounts
and contracts.
POPULATE.BAL.MVMT
POPULATE.BAL.MVMT populates the BALANCE.MOVEMENT file with movement information,

since the date held in the BACK.VAL.DATE field, on the BAL.MVMT.BVAL file. If this field is
blank, then the account or contract is up to date and does not need to be processed.
CALC.AVG.BAL.MVMT
This routine calculates the average balances for the records on the BALANCE.MOVEMENT file.
MI.PROCESS.RATE.DATE
Separate job to rebuild the RATE.CHANGE.DATE field on the BAL.MVMT.BVAL file. Whilst this
field is updated during the normal rebuild, this routine allows the refinancing rates to be extracted and
rebuilt separately to capture any change in the set up of the refinancing.
MI.PROCESS.REFINANCE
This routine extracts the refinancing rate from the date specified in the RATE.CHANGE.DATE field on
the BAL.MVMT.BVAL
MI.BUILD.COF.ENTRIES
This file is used to control the creation of records on the MI.COF.ENTRIES file, and allows the
building / rebuilding of the file. During the COB, the process MI.EOD.BUILD.COF references
process records on this file.

Associated routines
MI.BUILD.COF.ENTRIES$RUN
This is the routine that actually produces the MI.COF.ENTRIES records, processing each
BALANCE.MOVEMENT record and producing MI.COF.ENTRIES from the information held there.
MI.BUILD.STAT
This application is used to control the running of the processes defined on the
MI.STAT.DEFINITION file. Each process defined on the build record is run in turn.
MI.BUILD.STAT$RUN
Each process is run here, and the record on the source file examined for a match to the selections
defined on the MI.STAT.DEFINITION file. This routine updates the LAST.RUN.DATE field on the
MI.STAT.DEFINITION record.
MI.AUTO.GEN
This file references records on the MI.AUTO.MAPPING file and controls the building / rebuilding of
the associated records for the source file.
MI.AUTO.GEN$RUN
This routinely processes the records on the source file and, using the mapping rules defined on the
MI.AUTO.MAPPING application, produces MI.AUTO.ENTRY records from the underlying source
file.
COB Build Routines

There are a number of BATCH jobs that run during the COB to simulate the on line running of the
various build processes. These jobs reference a build file and produce records on the related source
file as follows;
Job Name Build File Source File

MI.EOD.BUILD.COF MI.BUILD.COF.ENTRIES MI.COF.ENTRIES
MI.EOD.BUILD.STAT MI.BUILD.STAT MI.STAT
MI.EOD.BUILD.PL MI.AUTO.GEN MI.AUTO.ENTRY
MI.EOD.BUILD.DATA.BASE MI.BUILD.DATABASE MI.DATA
COB Build Routines

Selections
Nearly all of the selections used within the MI module use the MI.SELECTION table.
MI.SELECTION records can be referenced on other MI.SELECTION records and hence it is
possible to build up complex definitions.
To aid in the performance of the matching routine, a cache of the MI.SELECTION records is held.
Hence any unused MI.SELECTION records should be reversed.
Also stores a cache for each record, of the list of selections that the record has had run against it and
whether the record matched the selection or not.
Hence, if a record is to be matched against one particular selection multiple times, the selection
should be present. For example, a line structure may look something like this:
LINE SELECTION OPERAND

LCY MORTGAGE MORTGAGE AND
LCY
LCY LOANS LOANS AND
LCY
LCY DEPOSITS DEPOSITS AND
LCY
FCY MORTGAGE MORTGAGE AND

FCY
ETC
Example line structure
In this case the record will attempt to be matched to MORTGAGE, LCY, LOANS and DEPOSITS.
If the record is a FCY record then it is possible to prevent the evaluation of the unnecessary selections
by switching the order of the selections. In this manner LCY will be evaluated once and then cached,
such that the evaluation on the match to the LCY LOANS and the LCY DEPOSITS line will be very
quick.
Although the selection method is used widely within the MI module, its most important use is in the
definition of the line structure and care should be taken when setting up the selection records for the
lines.
MI.SELECTION

If a null is to be matched then leave the criteria field blank, do not put in ‘’, NULL or anything else.
If there is only one criteria then using the OR operand will force the matching routine to drop out a
fraction earlier.
Associated routines
MI.DETERMINE.MATCH
This routine attempts to match a record to the list of MI.SELECTION ids it has passed.
For each record, a cache of the selection ids to which a match attempt has been made, and the result
of that match is held. Hence any often-used selections should be at the top of the list of selections.
As a general rule;
• When the selection operand is OR, tries to put the most common selection first.
• When the selection operand is AND, tries to put the least common selection first
MI.FIELD.JOIN
This routine is used to evaluate the various field names and I descriptors throughout the MI module.
This routine is used in place of the standard FIELD.JOIN routine for performance reasons, and makes
extensive use of caching in I_MI.COMMON.
Enquiry routines
MI.GET.NEW.BUDGET
This routine allows the latest budget figures to be incorporated into an MI enquiry without having to
rebuild the MI database. By calling this routine via ENQUIRY and passing it the key to the
MI.DATA record and the budget type of the new budget, the latest budget amount is returned to the
ENQUIRY via O.DATA.
This routine can only be called via the enquiry system, and expects the following argument to be
passed in O.DATA (the enquiry field)
MI.DATA.ID*BUDGET.TYPE
Where;

MI.DATA.ID is the full key to the MI.DATA record for which a budget is to be obtained.
BUDGET.TYPE is the MI.BUDGET.TYPE of the budget records that are to be incorporated.
MI.CALC.INT.RATE
This routine calculates an interest rate from a principal amount (e.g. the average balance) and the
interest earned / paid (sum of the interest accruals from CATEG.ENTRY) and is intended to be called
as an I descriptor.
The routine expects the following arguments;
MI.DB.ID - Id of the database.

MI.DATE - The period of the database.
INT.BASIS - The interest basis to determine the rate from.
PRIN.AMT - Principal to determine rate from.
INT.AMT - The interest amount to determine rate from.
And returns;
INT.RATE - The rate, which caused the interest to be earned.
APPENDIX
Diagrams
Layout of the MI.BUDGET.LINE text records
The routines MI.UPLOAD.BUDGET and MI.DOWN.LOAD budget allow MI.BUDGET.LINE

records to be exported from to a text file on the operating system. From there, the file may be
transferred to a PC and modified in another package, such as a spreadsheet. To aid the import of the
text file into PC applications, the file is held in a comma-delimited format. The first line of the file
contains the column headings, e.g.
Consolidate Consolidate REPORT Period Period Period Period

One Two LINE 1 2 3 4
MI.BUDGET.LINE Column Headings
Then each further line on the record reflects one BUDGET.FOR multi - value on the
MI.BUDGET.LINE record.
BUDGET_ Enrichment Enrichment Report Line Amt Amt Amt Amt

FOR One Two Enrichment 1 2 3 4
MI.BUDGET.LINE multi-value
Example;
Line one might read:
Product Category, Currency, REPORTLINE, 199601,199602,199603,199604
Subsequent Lines;
21050_CHF_TEST0010, Loans, Swiss Francs, Test Report Line 10, 100, 120,120,100
21050_USD_TEST0010, Loans, US Dollar, Test Report Line 10, 100, 120,120,100
Overview
Overview MI Structure

BALANCE.MOVEMENT
Balance Movement Structure

Profit and Loss Entries
Profit and Loss Structure

Budgets
Budgets Structure

Other Source Files
Other Source Files Structure

Management Information

Uploaded by

Copyright:

Available Formats

You might also like

Management Information

Uploaded by

Document Information

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

Management Information

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 Page 2 of 105

MI.REPORT.TYPE - Defining line structures for MI databases ..................................................... 38

TEMENOS T24 User Guide Page 3 of 105

Cross Reference Files ....................................................................................................................... 73

TEMENOS T24 User Guide Page 4 of 105

The main features of the MI module are:

TEMENOS T24 User Guide Page 5 of 105

MI System Design Overview

Each database can contain information from the following sources:

• Profit and loss entries CATEG.ENTRY

TEMENOS T24 User Guide Page 6 of 105

• Define groups of source information MI.SELECTION

MI.BUILD.DATABASE - controls the construction of databases. It can build databases on-line or

Flowchart showing process of Database construction

• Daily debit and credit movements.

TEMENOS T24 User Guide Page 7 of 105

• Average balances calculated on a calendar basis.

• Original. The balances as originally reported by 4 at the time.

During the month, all balances show month to date figures.

Structure of the MI parameter files

TEMENOS T24 User Guide Page 8 of 105

Structure of the MI Parameter Files

Use of Enquiries and REGENS

TEMENOS T24 User Guide Page 9 of 105

Creating a departmental hierarchy

Departmental hierarchy structure

Accessing the departmental hierarchy

TEMENOS T24 User Guide Page 10 of 105

Example part of standard selection record

TEMENOS T24 User Guide Page 11 of 105

Treatment of inter-departmental balances

Line1 Line 2 Line 3

Example budgeting breakdown

TEMENOS T24 User Guide Page 12 of 105

A special feature on MI.DB.DEFINITION enables the automatic generation of empty budget

Guide to Preparing a Budget

P&L Adjustments (MI entries)

TEMENOS T24 User Guide Page 13 of 105

Profit and Loss Allocation

Dept. 0001 Information Technology

Example of Profit and Loss Allocation

TEMENOS T24 User Guide Page 14 of 105

This is defined in the MI.PL.ALLOCATION table.

Refinancing (Cost of funds)

TEMENOS T24 User Guide Page 15 of 105

Specify refinancing accrual amount

Notional Costs or Margins on Funds (Additional Cost of funds)

TEMENOS T24 User Guide Page 16 of 105

TEMENOS T24 User Guide Page 17 of 105

Table for Refinancing/Additional Cost of Funds Specification Rules

TEMENOS T24 User Guide Page 18 of 105

Calculation of transaction unit costs

TEMENOS T24 User Guide Page 19 of 105

Calculation of average interest rates

Avg.Bal Interest Income Avg. Rate

The formula used is: