Posted by 
BALANCE MISMATCH
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.
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
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