BALANCE MISMATCH

wikibanking.info/2013/01/balance-mismatch/

A balance mismatch consists in a detection by the system of some differences in the

amounts recorded on the contracts and on the consolidation buckets, e.g. between
RE.CONSOL.XX (where XX is the name of the contract application) and
CONSOLIDATE.ASST.LIAB. There are two ways to check existence of balance
mismatches : Under UV, try to locate any presence of the text string “BALANCE
MISMATCH” in any report such as the G.L. or any other relevant report. Launch the
program RE.STAT.MISMATCH on the suspect report, if it has been identified.

STEP 1Check the HOLD ID in HC :

Using the GUI, after selecting the correct report, you have to note the HOLD ID, which is
the name of the file for this report under UV. On Classic, just execute a “see” on the
concerned record in hold Control to see the Hold ID. Example here = 110506969100 To
edit the GL under UV : ED &HOLD& 110506969100 To locate the text string : L
MISMATCH The editor will drive you directly to the concerned line (s). You need to note
those line(s) nb in the GL.

STEP 2Launch the program RE.STAT.MISMATCH :

If not exists, create a record “XYZ” which should contain the name of the GL report and the
range of lines you want to check.

BNK RE.STAT.MISMATCH VERIFY

KEY............... DAILY
---------------------------------------------------
1. 1 GB DESCRIPTION. BALANCES MISMATCH
2. 1 REPORT.NAME.... BILAN ACTIF / PASSIF
3. 1. 1 LINE.NO.ST.. 0001
4. 1. 1 LINE.NO.END. 9999
5 RECORD.STATUS.....
6 CURR.NO...........
7. 1 INPUTTER.......

Then launch a “Verify” on this record to print the result.

If the column called “Difference” is not empty, you are in trouble for those considered
line(s).

If you have the message “Missing in base file”, you just need to update the file
RE.CONSOL.XX and kill the concerned record. Example : ED FBNK.RE.CONSOL.MM
MM.1.TR.DEM.21030 etc…(without asset type at the end).Then DELETE.

STEP 3 Then, for the lines with mismatches, in the same way as the previous point,
launch the program RE.STAT.BAL.REC.

1/3
 RE.STAT.BAL.REC VERIFY

KEY............... BILAN.1010
------------------------------------------------------------------------------
1. 1 GB DESCRIPTION. SECURITIES
2. 1 REPORT.NAME.... BILAN ACTIF / PASSIF
3. 1. 1 LINE.NO.ST.. 1010 1010 Cte Liaison - Futures (2310)
4. 1. 1 LINE.NO.END. 1010 1010 Cte Liaison - Futures (2310)
5 RECORD.STATUS.....
6 CURR.NO...........
7. 1 INPUTTER.......

Then you get the list of all consolidation buckets concerned by the mismatches and all
contracts movements. We have here the first element of comparison for mismatches : the
contracts amounts. The consolidation keys ID are to be noted for the next step : Check
which amounts are stored in those specific keys in CONSOLIDATE.ASST.LIAB.

STEP 4Under UV, using the CONSOL ID noted :

LIST FBNK.RE.CONSOL.SPEC.ENTRY WITH CONSOL.KEY.TYPE EQ ‘CONSOL ID’ BY

OUR.REFERENCE TOTAL AMOUNT.LCY (OR .FCY) BREAK.ON OUR.REFERENCE

This command will give the sum of movements in consolidation keys by contract.

We then need to compare it with the result of RE.STAT.BAL.REC.

A second command :

LIST FBNK.RE.CONSOL.SPEC.ENTRY WITH OUR.REFERENCE EQ ‘MM970600001’ BY

CONSOL.KEY.TYPE TOTAL AMOUNT.LCY BREAK.ON CONSOL.KEY.TYPE

Allows to see if a contract has moved from one bucket to another.

STEP 5 Fax all the stuff to the Helpdesk.

This should be the last step for all junior consultants/users. If the total of the mismatches
gives zero, then the Helpdesk can give an OK to do a REGEN. A REGEN is a batch job
that clears all buckets for one application and recreates them with existing
records/movements in RE.CONSOL.XX. A REGEN does not include contingent entries. A
REGEN should always only be launched for one application at a time. Never activate
REGEN.ALL. Never activate REGEN.LC before testing it on a test environment before (not
consistent by the past…). Don’t forget to modify the batch sequences to get a new
calculation of CRB reports after the regen (e.g. activate the batch REGEN.CRF.RVL.PRT).

STEP 6 After approval from the Helpdesk, it is possible to update the consolidation
buckets under UV.

Input under UV :

ED FBNK.CONSOL.ENT.TODAY 1103799990.00

The ID of this record is : 1 to 5 = today’s date using internal format* 6 to 10 = Always

99990. 11 to 12 = sequence no
2/3
The global format of this file is as follow :

>LIST DICT FBNK.CONSOL.ENT.TODAY

DICT FBNK.CONSOL.ENT.TODAY 15:12:48 Page 1

Type &

Field……… Field. Field…….. Conversion.. Column……… Output Depth & Name……….

Number Definition… Code…….. Heading…….. Format Assoc..

@ID D 0 @ID 22L S

CONSOL.ENTRY.I D 0 CONSOL.ENTRY.ID 22L S

D
PRODUCT D 1 PRODUCT 2L S
TXN.REF D 2 TXN.REF 25L S
CURRENCY D 3 CURRENCY 3L S
CURRENCY.MARKE D 4 CURRENCY.MARKET 1R S
T
K.TYPE D 5 K.TYPE 12L S
LOCAL.CR D 6 LOCAL.CR 19R S
FOREIGN.CR D 7 FOREIGN.CR 19R S
LOCAL.DR D 8 LOCAL.DR 19R S
FOREIGN.DR D 9 FOREIGN.DR 19R S
ENTRY.ID D 10 ENTRY.ID 25L S
TXN.CODE D 11 TXN.CODE 3L S
CONSOL.KEY D 12 CONSOL.KEY 40L S
VALUE.DATE D 13 VALUE.DATE 11R S
MAT.DATE D 14 MAT.DATE 11R S
INT.RATE D 15 INT.RATE 11R S
INT.KEY D 16 INT.KEY 11L S
INT.SPREAD D 17 INT.SPREAD 11L S
SUPPRESS.POSIT D 18 SUPPRESS.POSITI 2L S
ION ON
EXCHANGE.RATE D 19 EXCHANGE.RATE 11R S
PRODUCT.CATEGO D 20 PRODUCT.CATEGOR 5R S
RY Y
CUSTOMER D 21 CUSTOMER 10R S
ACCOUNT.OFFICE D 22 ACCOUNT.OFFICER 4R S

The relevant fields are :

1 (Product) : The transaction product considered. (ex. SW, MM, …)

2 (TXN.REF) : ex. SW9715000012
3 (Currency) : ex. NOK
4 (Currency Market) : 1
5 (K.TYPE) : ex. FORWARDDB (see on considered consol. key)
7 FOREIGNCR (if relevant, or see DR) : ex. 100000000
11 (TXN.CODE) : NEW
12 (CONSOL.KEY) : (see on considered consol. Key; reproduce the key without the
asset type, the system will add it) ex. SW.1.TR.NOK…
13 (VALUE DATE) same value date as the consol. key. Ex. : 19980305

3/3