Globus Accounting Files

STMT.ENTRY

Account related entries are raised ON-LINE or OFF-LINE for all movements over Customer
and Internal Accounts - these entries are recorded in the STMT.ENTRY file.

All entries affecting Globus Category range 1 – 19999 are held in this file.

In addition to a transaction creating the STMT.ENTRY record an entry is also generated in

the ACCT.ENT.TODAY file - this file records all STMT.ENTRY records relating to a specific
ACCOUNT, the ACCT.ENT.TODAY file only holds references to transactions carried out
since the last EOD and is cleared in the Start of Day processing in BATCH.CONTROL.

The file ACCT.ACTIVITY, Actual account balance and other related files for Accounts are
built using the ACCT.ENT.TODAY file.

When the file is cleared during the EOD the contents are copied to the
ACCT.ENT.LWORK.DAY file.

General Points

ƒ The file is keyed by Universe internal date concatenated with user number and Universe
internal time - the date is the machine date.
ƒ Forward entries are keyed by 'F', external date and a sequence number - the date is the
value date of the transaction.
ƒ ALL forward entries for an account are held in a file ACCT.ENT.FWD
ƒ ALL forward entries for a transaction are held in a file TRANS.FWD
ƒ Frequency of statements is controlled by the file ACCOUNT.STATEMENT
ƒ All records printed on a statement are contained in a file called STMT.PRINTED this is
keyed by the account and the statement date, the data contained in this record is the
STMT.ENTRY ID
ƒ A summary of all statements printed for an account is held on the ACCT.STMT.PRINT
record, this is keyed by the account and the data represents the date the statements
were produced along with the opening balance for the statement.
ƒ Statement entries which do not relate to today, but have not yet appeared on a
statement are held in a file called ACCT.STMT.ENTRY

Page 1 of 26
CATEG.ENTRY

Profit and Loss entries are raised ON-LINE or OFF-LINE and are recorded in the
CATEG.ENTRY file.

All entries hitting Category codes over 50000 are held in this file.

Both income and expense details are held in the same file.

In addition to a transaction creating the CATEG.ENTRY record an entry is also generated in

the CATEG.ENT.TODAY file, the CATEG.ENT.TODAY file only holds references to
transactions carried out since the last EOD and is cleared in the Start of Day processing in
BATCH.CONTROL.

When the file is cleared during the EOD the contents are copied to the
CATEG.ENT.LWORK.DAY file.

General Points

ƒ The file is keyed by Universe internal date concatenated with user number and Universe
internal time - the date is the machine date
ƒ The CATEG.MONTH file holds details of all CATEG.ENTRY records by Category code
and month.

Page 2 of 26
RE.CONSOL.SPEC.ENTRY

The RE.CONSOL.SPEC.ENTRY file is so named as it contains the special entries used to

update the balances on the consolidation files.

These entries are comprised of entries that are not passed through the CATEG.ENTRY or
STMT.ENTRY files. The nature of entries held in this file would include, inter alia:

(i) Accounting entries raised for contracts

(ii) Accrual/suspense entries raised for Accounts or Contracts
(iii) Capitalisation entries for such Accruals
(iv) Contingent entries raised by the system for FX, LC etc.
1
(v) Static Changes
(vi) Entries raised for revaluation during End of Day

Online entries are created in CONSOL.ENT.TODAY and these are then used to create
RE.CONSOL.SPEC.ENTRY records during the EOD processing

Like each of the other source Accounting files the CONSOL.ENT.TODAY file is cleared
during the Start of Day processing and the contents are copied to
CONSOL.ENT.LWORK.DAY

TRANSACTION JOURNAL REPORT

The TRANS.JOURNAL2 report (the daybook of the bank) contains all the transactions and
movements for the day.

This report is built up from the contents of the ACCT.ENT.TODAY, CATEG.ENT.TODAY and
CONSOL.ENT.TODAY files.

1
Consolidation Entries are raised exclusively OFF-LINE for all movements in the
automated General Ledger account not supported by an “account” entry; they are
kept in the RE.CONSOL.SPEC.ENTRY file.

For example a customer’s sector could have changed from Partnership to Public
Company. This would initiate a Movement entry (for the balance held in the
respective account) from one group to the other.

A change in sign of the customer’s balance (from debit to credit or vice versa) would
necessitate a movement entry from one bucket to another. Such entries raised for
static changes are also held in the Special entry file.

Page 3 of 26
A number of other reports are also available which provide details of the current or previous
day's transactions.

TRANS.INV2 INVESTIGATION LISTING OF TODAYS ENTRIES

TRANS.INV4 INVESTIGATION LISTING OF TODAYS ENTRIES
TRANS.INV6 INVEST. LIST OF TODAYS ENTRIES WITH EXPANDED CRF INFO
TRANS.INVYEST2 INVESTIGATION LISTING OF YESTERDAYS ENTRIES
TRANS.INVYEST4 INVESTIGATION LISTING OF YESTERDAYS ENTRIES
TRANS.INVYEST6 INVEST. LIST OF YESTERDAYS ENTRIES WITH EXPAND CRF INF
TRANS.JOURNAL TRANSACTION JOURNAL (LIST OF ENTRIES)
TRANS.JOURNAL2 TRANSACTION JOURNAL (LIST OF ENTRIES)
TRANS.JOURNAL4 TRANSACTION JOURNAL (LIST OF ENTRIES)
TRANS.JOURNAL6 TRANSACTION JOURNAL (WITH EXPANED CRF INFORMATION)
TRANS.YEST2 LISTING OF YESTERDAYS ENTRIES
TRANS.YEST4 LISTING OF YESTERDAYS ENTRIES
TRANS.YEST6 LISTING OF YESTERDAYS ENTRIES WITH EXPANDED CRF INFO.

CREATION OF CRB (CENTRAL REPORTING BASE)

In GLOBUS the transaction data is used to feed the General Ledger, this is accomplished by
telling GLOBUS how you wish to analyse the data.

All financial information is held in 'consolidation keys' and 'buckets' - a consolidation key is
the key generated for each piece of financial data based on the CONSOLIDATE.COND
conditions and a bucket is the ASSET.TYPE for the data.

Any form of financial statement, register sub-ledger or general ledger can be constructed
using these keys.

Thus Globus holds financial information at a very base (low) level, from which the data is
consolidated in the manner desired.

Since all accounting data relate to either Asset & Liability or to Profit & Loss, they are held in
two separate files (CONSOLIDATE.ASST.LIAB & CONSOLIDATE.PRFT.LOSS)

CONSOLIDATE.COND

One of the first files that is set-up during Globus implementation is the
CONSOLIDATE.COND, this application defines the parameters used for creating
consolidation entries from transactions deals and contracts i.e. definition of consolidation
keys.

There are only two records in this table, one for Asset & Liability (A&L) and the other for
Profit and Loss (P&L) Different parameters can be defined for A&L data and for P&L data.

In this application the user will define the structure of the consolidation key and then define
where within each application this data will be found.

Page 4 of 26
ASSET&LIAB Record

The Asset&Liab Key is made up of Fixed and Variable Parameters. The fixed parameters
are four in number and are ‘System Supplied’. They are,

ƒ Application ID from which the deal emanates from (AC, LD, MM etc)
ƒ Currency Market (of the deal)
ƒ Position
ƒ Currency (of the deal)

In addition to the above the User can define up to twelve additional variable parameters, this
will allow deals to be analysed in detail

These parameters could be a value either on the customer table (static) or on the
application.

Classic examples of values on the customer table are Sector, Industry, Residence,
Nationality and Status.

At the Application level any value can be defined as a grouping parameter provided it is not
more than 10 characters in length.

An example of values from an application may be Category or the contract duration.

Local references included in both the customer and the application files could also be
defined as a parameter.

PROFIT&LOSS

The Profit & Loss key is made up of one fixed parameter (PL) indicating that it is a PL value
and up to 12 user-defined parameters plus the Currency (Currency in which the income or
expense was incurred).

The User specifies only the variable parameters and the system provides the indicator PL
and the Currency.

The parameters could be any value on the CUSTOMER table or the CATEG.ENTRY file,
provided the length of the field is not in excess of 10 characters.

Inclusion of Local reference fields is also permissible.

A parameter defined for the Asset & Liab ID can be used for PL also; if the AL key contains a
time definition, the same could be adapted for PL instead of this being re-defined.

This concept is especially when a Local Reference is included in the AL key and it is desired
to ‘copy’ the same reference to the PL key.

Page 5 of 26
Central Reporting Base (CRB)

CONSOLIDATE.ASST.LIAB (CAL)

The ID of the CAL file is the Consolidation Key and its structure would depend on the
‘Grouping criteria’ defined on the Consolidate.Cond.

This file maintains aggregate balance of a record (Key) by ‘Type’ (i.e. the nature of balance -
Debit, Credit, Suspense, Principal, Accrued Interest etc)

The balance in deal currency as well as local currency is maintained.

This file also holds the schedule balance by each maturity date to allow maturity split reports
to be produced.
2
The opening balance as of previous working day and the debit/credit movements for
previous day, both in foreign and local currency is also held.

CONSOLIDATE.PROFIT.LOSS (CPL)

The ID of the CPL file is the Consolidation key for PL and as in AL; the structure depends on
the grouping conditions on the CONSOLIDATE.COND record.

This file maintains aggregate balances for each consolidation key but in addition maintains
balances for each currency (yesterday’s opening balance and debit/credit movements for
yesterday, in both profit as well as local currency. In order to facilitate reporting of the current
month P&L and Prior months P&L YTD balance is also stored here.

At the Bank's financial year-end the CPL file transferred to the PLCLOSE category account
that is specified on the ACCOUNT.CLASS table - this is done by the PL.MOVE.TO.AL
BATCH job.

2
When viewed this file holds previous working day information as the CRF reports are produced prior to the date
change in the EOD

Page 6 of 26
ASSET.TYPE

Within a given CRB key there are different buckets (ASSET.TYPE).

The exhaustive list of Asset.Types available in G10.2.04 is given below:

Accrual - Category code for the income or expense – E.g. 50000, 51000, 51010 etc.
Suspended Interest – Category Code + SP e.g. 51000SP

Asset Type Contingent Modules

LIVECR N LD MM SC SW
LIVEDB N LD MG MM SC SW
LIVECMT C LD
LIVEPOS C AL
FORWARDCR F FR LD MG MM SC SW
FORWARDDB F FR LD MG MM SC SW
FORWARDCMT F LD
FORWARDPOS C AL
FXSPOTBUY C FX
FXSPOTSELL C FX
FXFWDBUY C FX
FXFWDSELL C FX
FXSPINTBUY C FX
FXSPINTSEL C FX
FXFWINTBUY C FX
FXFWINTSEL C FX
FXOPTBUY C FX
FXOPTSELL C FX
OVERDUECR N LD
OVERDUEDB N LD PD
NABCR N LD
NABDB N LD PD
DEBIT N AC
CREDIT N AC
SUSPENS N AC
CONTCR C AC FD MD
MMFIDCR C MM
MMFIDDB C MM
LINE C LI
UTIL C LI
PREADV C LC
ISSUE C LC
DEFPAY C LC
ACPTCONTRA C LC

Page 7 of 26
ACPTBANK C LC
ACPTHO C LC
ACPTSUBS C LC
COLL C LC
ADVICE C LC
CONFIRM C LC
OPEN C LC
ACPT C LC
PAYRES N LC
FWDCONTCR F FD MD
FWDCONTDB F MD FD
CONTDB C MD FD AC
FWDMEMODB F MD
MEMODB C MD
FWDMEMOCR F MD
MEMOCR C MD
NOTIONALCR C SW
NOTIONALDB C SW
MEMOCMT C LD
FWDMEMOCMT F LD
LINEMVMT c RE
OVERDUECO N PD
NABCO N PD
OVERDUEPR N PD
NABPR N PD
OVERDUEIN N PD
NABIN N PD
OVERDUETX N PD
NABTX N PD
OVERDUECH N PD
NABCH N PD
OVERDUEA1 N PD
NABA1 N PD
OVERDUEA2 N PD
NABA2 N PD
OVERDUEA3 N PD
NABA3 N PD
OVERDUEA4 N PD
NABA4 N PD
OVERDUEA5 N PD
NABA5 N PD

Page 8 of 26
REPORTING

The GLSHORT report is shown below and the procedure for setting up the GLSHORT report
is as follows

The GLSHORT report is a report that gives no analysis over the consolidation keys but
ensures that the system is in balance.

The RE.STAT.REP.LINE and the RE.STAT.REPORT.HEAD GL Short should be set up and

the report should be attached to the batch to ensure that it will run daily.

Page 9 of 26
RE.STAT.REPORT.HEAD FOR GLSHORT REPORT
REPORT.NAME....... GLSHORT
-----------------------------------------------------------------------
1. 1 GB DESCRIPTION. GENERAL LEDGER CHECK REPORT
2. 1 NOTES.......... REPORT TO CHECK THAT CRB IS IN
2. 2 NOTES.......... BALANCE IN LOCAL CURRENCY.
2. 3 NOTES.......... NOTE THAT CONSOLIDATE.COND HAS BEEN
2. 4 NOTES.......... SET WITH NON SELF-BALANCING
2. 5 NOTES.......... CONTINGENT AND FX ENTRIES.
2. 6 NOTES.......... ALSO, POSN ENTRIES SET TO 'NONE'
4. 1 GB HEADING..... CRB - GENERAL LEDGER CHECK REPORT
5. 1 LINE.NARR.SIZE. 5
6. 1. 1 GB NARR.HD.1 LINE
7. 1. 1 GB NARR.HD.2 NO
5. 2 LINE.NARR.SIZE. 35
6. 2. 1 GB NARR.HD.1 LINE
7. 2. 1 GB NARR.HD.2 NARRATIVE
8 SPLIT............. ALL
9 PROFIT............ LOCAL
10 AMOUNT.UNITS...... ALL
14. 1 COLUMN.TYPE.... CLOSBAL
29 MAT.TO.MONTH.END.. NO
30 MAT.INCLUSIVE..... Y

RE.STAT.REP.LINE FOR GLSHORT REPORT

REP.NAME.LINE.NO.. GLSHORT.0100
-----------------------------------------------------------------------
1 TYPE.............. DETAIL
2. 1. 1 GB DESC..... 0100
2. 2. 1 GB DESC..... NET ASSET / LIABILITIES
4. 1 TOTAL.ACCUM.... 1
6 SPACE.BEFORE...... 1
38. 1 ASSET.EXT.DUP.. DEF

REP.NAME.LINE.NO.. GLSHORT.0110
-----------------------------------------------------------------------
1 TYPE.............. DETAIL
2. 1. 1 GB DESC..... 1100
2. 2. 1 GB DESC..... CURRENT YEAR TO DATE P&L
4. 1 TOTAL.ACCUM.... 1
6 SPACE.BEFORE...... 1
53. 1 PROFT.EXT.DUP.. DEF

REP.NAME.LINE.NO.. GLSHORT.2000
-----------------------------------------------------------------------
1 TYPE.............. TOTAL
2. 1. 1 GB DESC..... 2000
2. 2. 1 GB DESC..... CURRENCY POSITION - ZERO LOCAL EQV
3 TOTAL.PRINT....... 1
6 SPACE.BEFORE...... 1
7 SPACE.AFTER....... 2

Page 10 of 26
 REP.NAME.LINE.NO.. GLSHORT.9000
-----------------------------------------------------------------------
1 TYPE.............. DETAIL
2. 1. 1 GB DESC..... 9000
2. 2. 1 GB DESC..... NET OFF BALANCE SHEET POSITION
6 SPACE.BEFORE...... 1
21. 1 ASSET.APPLIC.ID SW
37. 1 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21. 2 ASSET.APPLIC.ID AL
37. 2 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21. 3 ASSET.APPLIC.ID LD
37. 3 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21. 4 ASSET.APPLIC.ID MM
37. 4 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21. 5 ASSET.APPLIC.ID FR
37. 5 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21. 6 ASSET.APPLIC.ID MG
37. 6 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
37. 7 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21. 8 ASSET.APPLIC.ID FX
37. 8 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21. 9 ASSET.APPLIC.ID AC
37. 9 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21.10 ASSET.APPLIC.ID FD
37.10 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21.11 ASSET.APPLIC.ID MD
37.11 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS
21.12 ASSET.APPLIC.ID LC
37.12 ASSET.TYPE..... *OFFBAL OFF BALANCE SHEET ITEMS

RE.STAT.REQUEST & EB.STAT.PRINT

The RE.STAT.REQUEST file is used to load details of reports to be produced in the EOD
processing.

The ID of the RE.STAT.REPORT.HEAD of the desired reports that are to be printed is

specified in the ‘RE.STAT.REQUEST’ file.

The same RE.STAT.REQUEST is also specified in the BATCH record EB.STAT.PRINT.

Depending on frequency specified (daily, weekly, monthly etc.), the reports listed in the
RE.STAT.REQUEST file will be generated.

The End of Day would process these reports and store them in the Hold Control file.

The number of days for which a report should be stored in the Hold Control file is specified in
the SPF file in the HELD.RPT.RETENTION field.

Generation of reports is possible during the working day by verifying the appropriate
RE.STAT.REQUEST record.

Page 11 of 26
RE.STAT.REQUEST
KEY............... DAILY
------------------------------------------------------------------------------
1. 1 DESCRIPTION.... DAILY REPORTS
1. 2 DESCRIPTION.... RAPPORTS JOURNALIERS
2 LANGUAGE.CODE..... 1 English
3. 1 REPORT.NAME.... GLSHORT GENERAL LEDGER CHECK REPORT
4. 1 CONTENTS....... SUMMARY
5. 1. 1 OUTPUT.MODE. PRINT
3. 2 REPORT.NAME.... GLSHORT.CCY GENERAL LEDGER CHECK REPORT
4. 2 CONTENTS....... SUMMARY
5. 2. 1 OUTPUT.MODE. PRINT
3. 3 REPORT.NAME.... GLSTD GENERAL LEDGER - TRIAL BALANCE
4. 3 CONTENTS....... BOTH
5. 3. 1 OUTPUT.MODE. PRINT
3. 4 REPORT.NAME.... GLSTD.MVT GENERAL LEDGER - TRIAL BALANCE
4. 4 CONTENTS....... SUMMARY
5. 4. 1 OUTPUT.MODE. PRINT
5. 4. 2 OUTPUT.MODE. SS4 4 REPORT COLUMNS
3. 5 REPORT.NAME.... GLSTD.CCY GENERAL LEDGER BY CCY
4. 5 CONTENTS....... SUMMARY
5. 5. 1 OUTPUT.MODE. PRINT

For the reports to be produced as part of the batch run, the key of the appropriate record is
entered in the Data field of the EB.STAT.PRINT BATCH record.

BATCH PROCESS - EB.STAT.PRINT

------------------------------------------------------------------------------
1 BATCH.STAGE....... R100 REPORTING
3 PROCESS.STATUS.... 0 READY
4 BATCH.ENVIRONMENT. F FOREGROUND
6. 1 JOB.NAME....... EB.STAT.PRINT
8. 1 FREQUENCY...... D DAILY
9. 1 NEXT.RUN.DATE.. 28 MAR 2002
11. 1. 1 DATA........ DAILY
12. 1 JOB.STATUS..... 0 READY
13. 1 LAST.RUN.DATE.. 27 MAR 2002
17 CURR.NO........... 1
18. 1 INPUTTER....... 1_INPUTTER
19 DATE.TIME......... 03 OCT 94 16:21
20 AUTHORISER........ 1_AUTHORISER
21 CO.CODE........... GB-001-0001
22 DEPT.CODE......... 200

RE.STAT.LINE.CONT

This file contains the information about the CONSOL.KEY and the ASSET.TYPE
under that particular CONSOL.KEY. The id of the file is the REPORT
NAME.LINE NO(in other words this is the same as the RE.STAT.REP.LINE id).

A sample record is given below:

S.Machel Ave Branch RE.STAT.LINE.CONT SEE

REP.NAME.LINE.NO.. KBS.0050

Page 12 of 26
 -------------------------------------------------------------
-----------------
1 TYPE.............. DETAIL
2. 1. 1 GB DESC..... 0050
2. 2. 1 GB DESC..... Cash - Notes And Coins
4. 1 TOTAL.ACCUM.... 1
12 PROFIT.PERIOD..... ALL
15. 1 ASST AC.1.TR.ZWD.10000..19.
16. 1. 1 ASSET.TYPE.. DEBIT
15. 2 ASST AC.1.TR.ZWD.10000..22.
16. 2. 1 ASSET.TYPE.. CREDIT

-------------------------------------------------------------
-----------------
14 MAR 2002 15:00:08 USER (02 JAN) VIDYA1 [16,p2]
PAGE 1

Page 13 of 26
CONSOL FILES AND BALANCES

Each application has a Consolidation File where the records are stored in a sorted manner.
The sort is based on the consolidation key that each the deal is assigned.

Similarly, each application has a look up file for balance from where the account or deal
balance is fetched. The various consol files and balance files in globus are;

Application Consol File Balance File

AC * RE.CONSOL.ACCOUNT ACCOUNT
LD RE.CONSOL.LOAN RE.LD.ACC.BAL & LMM.ACCOUNT.BALANCES
MM RE.CONSOL.MM RE.LMM.BALANCES
PD RE.CONSOL.PD RE.CONTRACT.BALANCES
LC RE.CONSOL.LC RE.CONTRACT.DETAIL
DR RE.CONSOL.LC DRAWINGS
SW RE.CONSOL.SWAP RE.CONTRACT.BALANCES
MG RE.CONSOL.MG RE.MG.BALANCES
FID RE.CONSOL.FID RE.FD.BALANCES
FRA RE.CONSOL.FRA FRA APPLICATION
MD RE.CONSOL.MD RE.MD.BALANCES
FX RE.CONSOL.FOREX RE.FOREX.OPTION & FOREX
SC RE.CONSOL.SEC SC.TRADING.POSITION

The ID of the Consol file is the Consol Key, all deals that have been assigned this
consolidation key will be detailed in the record. The only exception is the Account file where
the ID is the Key plus the Asset.Type, this is because the ‘Account’ balance is subject to
change of sign while the sign of a ‘Contract’ balance remains unchanged throughout its
tenure.

CENTRAL REPORTS

CRF reports are the main reports from the Consolidated Reporting Base i.e. the General
Ledgers, Foreign Currency Control Ledgers etc.

CRB reports are based on the maijn CRF reports but contain details of the individual
contracts and accounts that make up each report line

CRD reports are Diagnostic reports providing a breakdonw of contracts and accounts that
make up each report line.

CRC reports are Company Consolidation reports in a Multi Company environment. These
reports are base reports like CRF reports but contain details for more than one company.

.The CRB is printed with the description and balance for each account or deal and also
provides currency wise total and the aggregate balance for each line.

The aggregate balance is returned from the Consolidate.Asst.Liab and the deal balance from
the relevant Balance file.

The live and forward balances are stored in separate fields in the Balance file and the CRB.

Whenever these balances are not equal a ‘Mismatch’ or an ‘Exception’ is reported on the
CRB.

Page 14 of 26
RE.BASE.CCY.PARAM

This file contains information necessary for producing CRB/CRF reports in a currency other
than the local currency.

To convert a report enter the key of this record in the BASE.CCY.PARAM field of the
appropriate record in the RE.STAT.REQUEST file. This alone is not enough to provide the
report. To enable the information to be extractecd for reporting, a record must be entered in
RE.BASE.CCY.REQ (q.v.) and the extract must be run by either:

Verifying the RE.BASE.CCY.REQ record online

Inputting and authorising the BATCH record EOD.RE.BASE.CCY.CRF so that it runs daily
and the currency code of the RE.BASE.CCY.PARAM record is in the DATA field.

CRF REPORT :-

Verifying the RE.STAT.REQUEST record or indentifying it in the BATCH job

EB.STAT.PRINT will produce the report.

CRB REPORT :-

To convert a CRB report append an asterisk and the currency code to the report name in the
BATCH record EOD.RE.BALANCE.PRINT, e.g. SBSUSA*USD.

MISMATCH

Mismatches are reported when the CRB files disagrees with the amounts that the application
files say are outstanding.

An example would be a MM deposit that was entered initially as USD 10,000.00 and had
several increase/decreases the same day. Due to a program error the last update to the MM
files recorded the amount as USD 50,000 when it should have been recorded as USD
55,000. The accounting entries are all correct so during the EOD the CRB system files and
entries are updated with a value of USD 55,000 - this would be recorded as a mismatch.

Types of Mismatch

Application Error
Where the application updates the accounting or it's own balance files with incorrect dates or
amounts.

CRB Error
Where the CAL is improperly updated and is in variance with the balance files.

Page 15 of 26
REBUILD OF CRB

!Warning

The CRF should ONLY be re-generated when no mismatches exist, or if the cause of
the mismatch is known and investigation has proved that ALL of the underlying
contracts and entries are correct.

Running a regen will destroy the CRF audit trail and if run when incorrect contract
entries exist there is a possability that the regen will put Globus out of balance.

Batch

The CRF can be re-built by running REGEN jobs in the Batch.

A rebuild will be necessary when there are alterations made in the Consolidate.Cond (new
parameters added). If the Consolidate.Cond is altered, deals input from that day onwards
would be assigned the keys as per revised definition, but the old records would continue to
have the existing keys.

If the user desires to re-define the key for existing records (in Live file) also, then a REGEN
is warranted. REGEN can be run for a specific application only or for ALL.

If the Consolidation parameter is revised only for AC, then a REGEN for AC application only
would suffice.

It is recommended that this re-creation is performed after the production of the day’s usual
reports, this should be followed by an additional production of each of the standard reports to
ensure that balances etc. are unchanged.

A REGEN will clear the Consolidate.Asst.Liab balance, the RE.CONSOL file and then
rebuild as in the first end of day.

A selective REGEN like RE.CRF.ACCOUNT would clear only RE.CONSOL.ACCOUNT and

all CAL keys beginning with AC.

Online

RE.CLEAR.CONSOL.REQ

Before an on-line rebuild of the system can take place it is necessary to clear the appropriate
part of the CRF.

This can be done by verifying the appropriate RE.CLEAR.CONSOL.REQ record.

Page 16 of 26
RECREATE

The following programs can be run from the 'Awaiting Application' prompt to rebuild the
appropriate area of the CRB, this can only be done when the RE.CLEAR.CONSOL.REQ for
the related application has been run.

RE.RECREATE.AC RE.RECREATE.ACCOUNT RE.RECREATE.AL

RE.RECREATE.DG RE.RECREATE.FD RE.RECREATE.FOREX
RE.RECREATE.FRA RE.RECREATE.FX RE.RECREATE.LC
RE.RECREATE.LI RE.RECREATE.LOANS RE.RECREATE.MD
RE.RECREATE.MG RE.RECREATE.MM RE.RECREATE.MMT
RE.RECREATE.PD RE.RECREATE.PL RE.RECREATE.POSITION
RE.RECREATE.PROFIT.LOSS RE.RECREATE.SW

EB.EOD.ERROR

An EB.EOD.ERROR is primarily a system generated warning messages created in the

online stage of batch.

The existence of an error will be recorded in the EB.EOD.ERROR report and the details in
the EB.EOD.ERROR.DETAIL report.

TYPES OF EB.EOD.ERRORS

REVAL 401
Foreign currency position does not equal foreign currency non-contingent CRB.

REVAL 402
Local profit and loss plus non-contingent CRB does not net off

REVAL 403
Contract exception has occurred

REVAL 402 & 403 errors are only experienced when using the Contract Reconcilliation
module.

Page 17 of 26
REVAL.401

REVAL.401 errors are caused primarily because of incorrect position updates on input,
reversals and deletions of a contract.

The reason that these incorrect updates can lead to problems is because the POSITION file
is updated on-line when a contract involving foreign currency is input (not authorised)

The POSITION file is updated as a result of POS.MVMT.TODAY entries, these entries are
copied to POS.MVMNT.LWORK.DAY during the EOD and are then copied to the
POS.MVMT.HIST file, the days history maintained in this file is controlled by the DAYS.HIST
entry on the SPF SYSTEM record.

The CRB as we have seen is only updated during the EOD and as a result of CATEG, ACCT
& CONSOL.ENT.TODAY records - the fact that the POSITION file and the CRB are updated
at different times and by different data can lead to these 401 errors.

Page 18 of 26
An EB.EOD.ERROR will be identified during the EOD batch, for this reason we know that
the cause of the error occurred the previous day.

To identify the contract(s) causing the error it is necessary to ensure that all currency
updates in the POS.MVMT.LWORK.DAY are matched by updates to the CRB, we already
know that all of our day's transactions are contained in the TRANS.JOURNAL2 report and
this is what we use to check the position updates.

The EB.EOD.ERROR will identify a CURRENCY.MARKET, TRADING.POSITION, &

CURRENCY that can be used to produce a listing of the POS.MVMT.LWORK.DAY file;

The transactions detailed on this listing can then be matched against the
TRANS.JOURNAL2 report to identify the transaction causing the error.

When the source of the error has been identified it is important to trace this to the application
to ensure that we resolve the issue in future software releases, in order to do this you should
obtain a copy of the relevant contract and it's history, along with a listing of the JOURNAL
records relating to the transaction.

CORRECTION OF REVAL.401 ERRORS

Page 19 of 26
Automatic Correction
Exceptions between Position and CRB totals can be automatically corrected using the
CORRECT.EXCEP field in the EB.SYSTEM.SUMMARY record.

The POSITION record for the Currency, market and position type for DEALER.DESK ‘00’ will
be adjusted by the exception amount.

If a correction is made an adjustment entry is posted in local currency to the suspense

account of the category defined in Consolidate Cond.

Manual Correction
Corrections can also be made by manually editing the two POSITION records.

The POSITION record has three fields and is keyed on

Page 20 of 26
EB.SYSTEM.SUMMARY

This application is maintained on a daily basis and a record is held for each system working
day. Foreign currency position totals vs. CRB non-contingent totals are held by market,
position type and currency (e.g. 1.TR.GBP). Any exception between the figures is recorded.

Both the foreign and local equivalent amounts are recorded.

Where contract exceptions have been corrected the total correction amount is also shown.

The local currency total of non-contingent asset and liabilities in the CRB together with the
local currency profit and loss totals is recorded.

Page 21 of 26
JOURNAL

The JOURNAL file hold an 'after image' of each transaction updated in the Globus, this file is
primarily used to recover the database if any transactions become corrupted during the
update phase.

An additional use of this file is to identify records that get updated by a particular transaction.

Below is an FT transaction in INAU status, and then the same record after having been
authorised;

Page 22 of 26
By listing the F.JOURNAL file at UniVerse we can see the files and records that got updated
at each stage above;

Page 23 of 26
@ID......... 1
@ID......... 1
FWT......... FBNK.ACCOUNT 18902
. FBNK.ENTRY.HOLD FTFT0013700001
. FBNK.PM.TRAN.ACTIVITY FT0013700001
. FBNK.PM.DLY.POSN.CLASS FTASC.1.00.TR.USD.20000516.8
. FBNK.PM.POSN.REAL.TIME CAS.AA.USD.20000516.8.CAL
. FBNK.PM.POSN.REAL.TIME GAP.AA.USD.20000516.8.CAL
. FBNK.FUNDS.TRANSFER$NAU FT0013700001
.
TXN.REF..... FT0013700001
APPLICATION. FUNDS.TRANSFER
FUNCTION.... I
TIME........ 17:07
DEPT........ 1
USER........ VIDYA1
SIZE........ 2173
COMPANY..... GB0010001

@ID......... 2
@ID......... 2
FWT......... FBNK.FUNDS.TRANSFER$NAU FT0013700001
. FBNK.ACCOUNT 18902
. FBNK.ACCOUNT 18918
. FBNK.ENTRY.HOLD FTFT0013700001
. FBNK.STMT.ENTRY 120910029362410.000001
. FBNK.ACCT.ENT.TODAY 18902
. FBNK.STMT.ENTRY 120910029362410.000002
. FBNK.ACCT.ENT.TODAY 18918
. FBNK.FUNDS.TRANSFER FT0013700001
. F.DE.O.HANDOFF D20010206002936241201
. F.DE.O.KEYLIST D20010206002936241201
. F.DE.O.HANDOFF D20010206002936241202
. F.DE.O.KEYLIST D20010206002936241202
.
TXN.REF..... FT0013700001
APPLICATION. FUNDS.TRANSFER
FUNCTION.... A
TIME........ 17:20
DEPT........ 1
USER........ VIDYA2
SIZE........ 3566
COMPANY..... GB0010001

Page 24 of 26
 HELP DESK DOCUMENTATION

The following reports should be enclosed when issues are logged to Helpdesk regarding
mismatches and EB.EOD.ERRORS.

MISMATCHES
ƒ RE.STAT.MISMATCH report
ƒ RE.STAT.BAL.REC report
ƒ Contract Balances
ƒ Contract Details
ƒ Accounting entries created by contract.

EB.EOD.ERRORS

ƒ EB.EOD.ERROR
ƒ EB.EOD.ERROR.DETAIL
ƒ EB.SYSTEM.SUMMARY (if using Contract reconcilliation)
ƒ POS.MVMT.LWORK.DAY or POSVMT.HISTORY
ƒ Contract Details
ƒ TRANS.JOURNAL Report
ƒ GLSHORT report

GENERAL LEDGER Out of Balance

ƒ CRF/CRB REPORTS Showing out of balance

ƒ GLSHORT report
ƒ TRANS.JOURNAL
ƒ EB.SYSTEM.SUMMARY (if using Contract reconcilliation)

We recommend that all of the above reports should be retained for a minimum of 25 bank
days. The report retention period should be set up in the REPORT.CONTROL record for
each report - this will override the default period set on the SPF.

The DAYS.HIST entry on the SPF should be set to match the retention of the above reports -
please note that this will have a sizing implication for the POS.MVMT.HIST file.

()((((((((((((((((((((((((((((((((((()))))))))))))))))))))))))))))))))))((((((((((((((((((((()))))))))))))))))))))(((((((()

es investigation – should be investigated daily as there is no history maintained in the system.

NMB report to be executed run the following commands first:

1. RE STAT MISMATCH V CHECK
2. RE STAT BAL REC V CHECK
3. HC 2 LK …CRD…
4. Analyse CRD Reports per Branch
a. Pick key with diff
b. Check the key in cal
c. Check the key in RE.CONSOL.SPEC.ENTRY listing either;
i. Stmt.entry
ii. Spec. entry
iii. Contract file

Page 25 of 26
key mismatches copy key ex CRD, log into relevant Branch, on command line type CAL S then paste key
rections may result in GL Differences if they are one sided.

Page 26 of 26