Sign in

Blog · Data quality and reconciliation · Investment banking

Reconciling the desk to the benchmark submission: a quarterly checklist for institutional sales

A checklist for the quarter-end reconciliation between an investment bank's sales desk roll-up and the revenue it submits to its benchmark provider: product mapping, client mapping, period cut, joint coverage and the variance report that turns three weeks of email into one page.

By CoviragePublished 16 September 20263 min read
The short answerThe desk's roll-up must equal the benchmark submission for the same quarter to the penny, on the same client and product taxonomy. Reconcile in five steps: map every product code in the ledger to the submission's product hierarchy, map every client to one identifier, cut both at the same date, resolve joint coverage to one owner, and produce a variance report by level. Zero variance, or a named line for every difference, before the submission goes.

Every quarter, an institutional sales desk submits revenue by client and product to its benchmark provider, and every quarter the desk's own management report says a slightly different number. The difference is small, unexplained, and the reason the wallet share figures that come back are trusted less than they should be. This checklist closes it.

What has to be true

desk roll-up revenue, this quarter = benchmark submission revenue, this quarter

on the same client identifiers, the same product hierarchy and the same period cut, with every difference a named line.

The checklist

1. Product mapping. Every product and sub-product code in the revenue ledger maps to exactly one node in the submission's product hierarchy. Codes with no mapping are listed with their revenue. Codes mapped to two nodes are listed. The mapping table is kept from quarter to quarter and changes are dated.

2. Client mapping. Every client code in the ledger maps to one submission client identifier. Subsidiaries roll to the parent the submission uses. Unmapped client revenue is listed.

3. Period cut. The ledger export and the submission are cut at the same date and on the same accrual basis. Trades booked after the cut but dated inside the quarter are listed as a timing line.

4. Joint coverage. Every client has one primary salesperson for the roll-up. Clients with two are listed and resolved to one, with the secondary kept as an attribute. Otherwise salespeople sum to more than the desk.

5. Variance report. After the four mappings, the roll-up is computed and compared to the submission at every level: desk, region, salesperson, client, product. Each level's variance is shown with the rows that explain it.

The variance report

Level Roll-up Submission Variance Explained by
Desk 9.874 9.874 0.000
Japan 6.631 6.631 0.000
Asia North 2.143 2.143 0.000
Australia 1.100 1.100 0.000
By product: FX forwards 1.212 1.190 +0.022 Sub-product FXF-2 mapped to swaps in submission; corrected
By client: 2291 2.102 2.102 0.000

The one non-zero line has a name and a fix. That is a reconciled desk.

Where it goes wrong

Mapping done fresh each quarter. The same product mapped differently in two quarters makes the trend meaningless. Keep the table; date the changes.

Submission built from a different source than the roll-up. If the submission comes from the finance ledger and the roll-up from the desk's own system, they will never agree, and the reconciliation becomes a permanent project. Build both from the same rows.

Joint coverage left unresolved. The desk total is right, the salesperson totals are wrong, and every wallet share by salesperson inherits the error.

Variance accepted as noise. A one percent unexplained variance is a mapping error that will grow. Zero or named, every quarter.

One page, every quarter

Run on the same exports each quarter, the five steps produce the variance report in minutes, and the submission goes out reconciled. When the benchmark's wallet estimates come back, they join the same identifiers and the wallet share figures are trusted from the first screen. Covirage runs this reconciliation inside the bank's tenant on an enterprise deployment. The investment banking page describes the setup, and the five reconciliation checks are the general form of this checklist.

Questions people ask

Why does the roll-up need to match the submission?

Because the benchmark provider's wallet estimates come back keyed to the submitted clients and products. If the desk's own view of a client differs from what was submitted, the wallet share computed from the two is wrong, and nobody can say by how much.

What is the usual size of the variance before reconciliation?

On a desk that has never reconciled, a few percent, made mostly of product mapping differences and one or two clients under two salespeople. After the first quarter it should be zero with a short list of named adjustments.

Can this be done without client names leaving the bank?

Yes. Both the roll-up and the submission use the bank's client identifiers, and the reconciliation works entirely on those.

Related reading

Data quality and reconciliation · Investment banking

Coverage officer transitions: handing over a client list without losing recency

How an investment bank's coverage group manages a banker's departure or move from the coverage file and the contact log: the clients whose last contact was with the departing banker, the days since any other banker touched them, the fee wallet at risk, the handover list ranked by it, and the ninety-day check that says which clients the new officer has actually met.

16 Sept 20262 min readWallet share and penetration · Investment banking

Fee wallet per client: measuring share of a client's investment banking fees

How an investment bank's coverage group estimates each client's total fee wallet across products from deal data and its own fee ledger, computes the bank's share per client per product, sets the expected share from clients where the bank is a lead relationship, and ranks the clients whose wallet is largest and whose share is lowest, with the product where the gap sits.

16 Sept 20263 min readBoard and management reporting · Investment banking

League table position against client wallet: where the bank ranks where it matters

Why a bank's league table position by product describes the market and not its clients, how to compute the bank's rank within each covered client's own fee wallet from public deal data and the fee ledger, the clients where the bank is top-three in the market and fifth at the client, the sector teams whose client ranks lag their market ranks, and the list of clients where one product mandate would move the bank from fifth to second.

16 Sept 20263 min readForecast and pipeline · Investment banking

Pitch-to-mandate conversion by sector team: what a bank pitches and what it wins

How an investment bank's coverage and product groups measure pitch-to-mandate conversion from the pitch log and the mandate register: pitches made per sector team and product, mandates won, conversion by count and by estimated fee, the senior hours per pitch from time or calendar records, fees won per senior hour by cell, and the sectors and products where the bank pitches most and wins least.

16 Sept 20263 min read