Fin Maverick
Foundations VocabularyAccounting & ReportingEconomics & MacroQuant Methods & ProgrammingBusiness & Company AnalysisCorporate Finance & ValuationBehavioural Finance
Banking & Market InfrastructureFixed Income & RatesDerivatives & Structured ProductsPublic EquitiesTransactions & DealsPortfolio ConstructionFunds & AMCs
Private Markets & AlternativesRisk, Treasury & ControlAI & Digital FinanceStochastic Calculus & PricingWealth & Personal FinanceIndian Markets & RegulationProfessional Practice
CalculatorComparison
Frameworks
Explore Bootcamps
Equity ResearchPortfolio ManagementMutual Fund MasteryFinancial LiteracyInvestment Banking Analyst
Private Equity AnalystHedge Funds AnalystBreaking Into VCBreaking Into QuantsAI For Finance
Financial Analyst ProgramRisk Management ProgramPrivate Wealth ManagementDebt Capital MarketsDerivatives Foundation
Explore Internships
Equity Research InternMutual Fund Intern
Portfolio Management InternFinancial Literacy Intern
Explore Micro Courses

Equity Research6

Writing an Investment ThesisBuilding a Discounted Cash FlowReading an Annual Report FastReading a Sector Before a CompanySpotting Quality of Earnings Red FlagsBuilding a Revenue Forecast From Drivers

Portfolio Management3

Rebalancing: When, Why and What It CostsStrategic and Tactical Asset AllocationMeasuring Risk in a Portfolio

Mutual Fund Mastery3

Comparing Funds Without Being FooledHow a NAV Is Struck and Which Day You GetReading a Fund Factsheet Properly

Derivatives Unlocked4

Hedging a Real ExposureThe Greeks, PracticallyFutures, the Basis and What Moves ItReading an Option Payoff

AI For Finance2

Retrieval and Grounding for FinanceDocument Extraction in Finance

Breaking Into Quants4

Backtesting a StrategyHypothesis TestingCleaning Financial DataRegression for Finance

Breaking Into VC3

Sizing a MarketReading a Term Sheet as a FounderHow a Venture Round Actually Works

Financial Analyst Program4

Common Size and Trend AnalysisReading a Cash Flow StatementRatio Analysis That Says SomethingBuilding a Working Capital Schedule

Risk Management Program2

Credit Exposure and How It Is ReducedValue at Risk and What It Hides

Investment Banking Analyst3

Precedent Transactions and Why They DifferReading a Term Sheet StructurallyBuilding a Comparable Companies Table

Private Wealth Management3

Tax Aware Portfolio DecisionsBuilding a Client Risk ProfileGoal Based Planning Arithmetic

Debt Capital Markets3

Analysing an Issuer's CreditDuration and What It Does Not Tell YouBond Pricing and Yield Mechanics

Private Equity Analyst2

Fund Waterfalls and CarryThe LBO in Structure

Hedge Funds Analyst2

Short Selling MechanicsLong Short Mechanics
Courses
Explore Career Roadmaps
Investment Banking AnalystEquity Research AnalystVC AnalystPrivate Equity AnalystHedge Funds Analyst
Quant AnalystAI For FinanceFinancial Analyst ProgramPrivate Wealth ManagementDebt Capital Markets
Risk Management ProgramDerivatives FoundationPortfolio ManagementMutual Fund Mastery
PartnershipsShowdown
Log inSign up
AI, Automation & Digital Finance
1AI Foundations
Artificial Intelligence in FinanceAlgorithmNeural Networks and Deep LearningMachine LearningArtificial Intelligence vs Machine…Computer Vision in FinanceTraining Data and LabelsNatural Language Processing in Finance
2Generative AI
Generative AIGenerative AI vs Predictive AILarge Language ModelsEmbeddingsHallucinationFine TuningPrompting vs Fine TuningThe PromptThe Context WindowTool CallingGroundingVector DatabasesRetrieval Augmented GenerationRAG vs Fine Tuning
3Automation and Workflow
Workflow AutomationAutomation vs AugmentationHow to Map a…Straight-Through Processing and Exception…Robotic Process AutomationRule EnginesMachine Learning vs Rule-Based…
4Document and Operations AI
Intelligent Document ProcessingBatch vs Real-Time vs…Document Classification vs Entity…Service Level AgreementsCase ManagementHow to Document Data…Reconciliation AutomationOptical Character Recognition and Data ExtractionConfidence Scores
5Customer Systems, Identity and Digital Assets
Digital IdentityConsent ManagementBlockchain and Distributed LedgerChatbots and Conversational AIFrom Use Case to ProductionDigital Assets and TokenisationDigital SignaturesData Sharing in FinanceElectronic KYC and Digital Onboarding
6Credit and Fraud Systems
The Fraud AlertCredit Decisioning SystemsHuman in the Loop…Adverse ActionAnomaly DetectionThe Decision ThresholdCredit Score vs Credit DecisionAlert Triage and EscalationFraud Detection and Transaction MonitoringFraud Model vs Credit ModelHow to Build Human…
7Governance, Data and Vendors
AI Governance and the AI PolicyHow to Create an…Explainability and Interpretability ComparedThe AI VendorBias and Fairness in Financial AIShadow AIAccess Control and Data MinimisationCloud Computing in FinanceData Lineage and Master DataData ResidencyThe AI Use Case Register and Model InventoryThe Model Owner
8Model Performance, Monitoring and Resilience
Model DriftFalse Positives and False NegativesClassification MetricsAdversarial AttacksModel TestingBias, Fairness and Explainability…Stopping an Automated SystemModel ValidationAI Governance vs Model Risk ManagementPrompt InjectionHow to Create an…

The AI Use Case Register and Model Inventory: What Each Holds

A use case register lists what a firm is using artificial intelligence for, one line per use. A model inventory lists the components inside those uses, so a single register line can hold nine of them. The register carries who approved a use and who answers for it; the inventory carries what is actually running. Completeness measured on the day of sign-off is the number that says whether either is real.

Both of these things are lists, and a list is only ever as good as the day somebody wrote it. Everything in this guide comes out of that one sentence. An entry is a set of statements that were true once. A register is a count that was right once. So the only useful question to ask about either of them is how quickly it stops being right, and what interval of re-checking a firm can afford. At Sumeru Bank Limited, invented, that question turns out to have an exact answer, and the answer is stranger than most people expect when they first meet it.

What is a use case register, and what is it a register of?

The point is easiest to see in a household rather than a bank. Somebody sits down to write out everything the household pays for every month. One line says the school run. The school run line quietly contains a car, a fuel card, an insurance renewal and half of somebody's morning. The list was never meant to be a list of car parts, so nobody writing it thinks that is a problem. The list was meant to name the things the household does. Anybody in the house can read it and recognise the household in it.

A use case registerThe list of the uses a firm has, one line per use rather than one line per component. is that list, written for a firm and written about the uses it has put artificial intelligence to. One line per use. The unit of a register is the use, not the component and not the model, and every confusion that follows on this subject comes from somebody quietly swapping those units. At Sumeru Bank Limited the whole retail personal loan intake and decision chain is one line. The chain takes an application started on a handset and returns a decision, and in one steady month it took 10,000 applications and carried 8,600 of them to a decision. Nine separate components sit inside it. The chain is still one line.

Four other lists get brought to meetings and called a register, so saying plainly what a register is not is worth the space. A register is not a list of models. The model inventory set out below is a different artefact. A use built inside a spreadsheet raises no invoice and would never appear, so a register is not a list of software the firm has bought either. A workflow records what happened to a request and a register records what is running now, so a register is not an approval workflow. A project ends and a use case does not, so a register is not a project list: at this invented bank the intake chain went live in month 4 and the project closed, and the entry describing it has to stay true for as long as the chain keeps deciding files.

Try it out

What does one line of a use case register describe?

What is a Model Inventory, and what does it count instead?

The second list goes underneath the first. A model inventoryThe list of the components inside those uses, which is a longer list of smaller things. counts components rather than uses: every fitted model, every written rule set, every reading step, each on its own row. Back in the household, this is the list of the car, the fuel card and the insurance renewal. The inventory is longer and duller, and it is the only one of the two that can say what is actually running at four o'clock on a Tuesday.

At Sumeru Bank Limited the two lists came out at 14 and 45. Fourteen uses in the register after the month 10 sweep, and 45 components in the inventory underneath them at the month 12 validation, an average of 3.2 components a use. Neither list can answer the other's question, and a firm holding only one of them has a blind side it usually cannot name. Held alone, the register says what was approved and who answers for it, and cannot say what is running. Held alone, the inventory says what is running, and cannot say what any of it is for or who agreed to it.

TWO LISTS, COUNTING TWO DIFFERENT THINGS THE USE CASE REGISTER 14 LINES 1 THE RETAIL LOAN INTAKE AND DECISION CHAIN 13 more lines, one for each of the other uses THE MODEL INVENTORY 45 ROWS The nine highlighted squares are the same thing as the one highlighted line on the left: 20.0 per cent of all 45 components. ONE LINE ON THE LEFT IS NINE THINGS ON THE RIGHT. 14 uses over 45 components, an average of 3.2 a use. The short list says who approved it. The long list says what is running.
Sumeru Bank Limited's register held 14 lines while the inventory underneath it held 45 component rows, an average of 3.2 components to a use. Those nine components inside one chain make up 20.0 per cent of every component the bank runs, and they sit inside a single line of the register.
Try it out

A register has 14 lines. How many components does that say anything about?

Why can one entry hold nine components, and why is that not a fault?

People meeting these two lists for the first time usually want them to match, and when they do not, the instinct is to call the register wrong. The register is not wrong. The register is answering a different question at a different grain, and the mismatch is the most informative thing on either list.

Look at what a filled entryOne line of the register, being a set of statements about one use that were true on a stated date. actually looks like at this invented bank. Entry 1 says the use decides retail personal loan applications, that it serves retail credit, that Revathi Balan is accountable for it, that it was built rather than bought, and that nine components sit inside it. Underneath, in the other list, those nine have a row each: an identity match step and four other written rule sets, and four components that learn from data. Five of the nine learn and four are rules somebody wrote. The register line states that the bank decides loans this way; only the inventory rows reveal that a written rule, not a fitted model, touches every single file.

ONE ENTRY, AND THE NINE ROWS SITTING UNDERNEATH IT USE CASE REGISTER · ENTRY 1 · SUMERU BANK LIMITED 1 WHAT IT DOES Decides a retail personal loan application 2 BUSINESS AREA Retail credit 3 NAMED ACCOUNTABLE PERSON Revathi Balan, head of retail credit 4 BUILT OR BOUGHT Built 5 COMPONENTS INSIDE IT 9, of which 5 learn and 4 are written MODEL INVENTORY · THE NINE COMPONENTS 1 identity match step WRITTEN own machines 2 liveness check on the selfie LEARNS bought service 3 document classifier LEARNS rented capacity 4 field reading and extraction LEARNS rented capacity 5 income corroboration rules WRITTEN own machines 6 scoring model LEARNS own machines 7 fraud rules on the book WRITTEN own machines 8 drafting assistant LEARNS own machines 9 workflow router WRITTEN own machines THE ENTRY IS ONE LINE. THE INVENTORY IS NINE ROWS. NEITHER ANSWERS THE OTHER'S QUESTION. The nine are 20.0 per cent of the bank's 45 components and sit inside 1 of its 14 entries, being 7.1 per cent of the entries.
One filled entry at Sumeru Bank Limited names the use, the business area, the accountable person, whether it was built or bought, and a component count of nine. Only the nine inventory rows underneath say which of them learn, which are written, and that the one touching every file is a written rule.

Now the shape of the thing. Across the 14 uses the average is 3.2 components. Entry 1 holds 9, or 2.8 times that average. The other 13 entries hold 36 components between them, an average of 2.8 each. Components cluster in the one or two uses that are really systems rather than steps, so an average component count describes almost none of the entries. This is the same lesson the household list teaches: the school run line and the streaming subscription line look identical on the list and are nothing alike underneath. A register that carried a size against each line would be a better register, and almost nobody builds one that way.

COMPONENTS PER ENTRY: ONE BAR AGAINST THIRTEEN 10 5 0 COMPONENTS 9 THE AVERAGE, 3.2 COMPONENTS A USE ENTRY 1 the other 13 entries, drawn at their common average of 2.8 components each ONE ENTRY HOLDS 2.8 TIMES THE AVERAGE AND 20.0 PER CENT OF EVERY COMPONENT THE BANK RUNS.
Components cluster rather than spread: entry 1 at Sumeru Bank Limited holds 9 of the 45 components while the other 13 entries hold 36 between them, an average of 2.8 each, so the register's average of 3.2 a use describes almost no entry on the list.

What does one entry have to carry, in twelve numbered fields?

An entry is only worth writing if somebody can be refused an answer by looking at it. Sumeru Bank Limited settled on twelve numbered fieldsOne of the twelve statements an entry carries. Each exists because a question would otherwise have no answer., and the numbering matters at that bank because every later record cites a field by its number rather than by quoting it.

Field 1 is what the use case does, in one sentence somebody outside the team can read. Field 2 is which business area it serves. Field 3 is the named accountable person. Field 4 is built or bought, and from which supplier where it was bought. Field 5 is the components inside it, and whether each learns or is written. Field 6 is what data it consumes and on what basis. Field 7 is what its output does and to whom. Field 8 is whether a person stands between the output and its effect. Field 9 is the date it was approved and by whom. Field 10 is the date it was last reviewed and by whom. Field 11 is the route back to a manual process and the date it was last rehearsed. Field 12 is the date of the next re-approval. Each of the twelve exists because a question somebody will eventually ask would otherwise have nowhere to land, and a thirteenth field that answers no such question is furniture.

TWELVE FIELDS, AND THE QUESTION EACH BAND ANSWERS WHAT IS IT? readable by an outsider 1 What the use case does, in one sentence 2 Which business area it serves WHO ANSWERS? 3 The named accountable person HOW IS IT MADE? the link to the inventory 4 Built or bought, and from whom where bought 5 The components inside it, and which of them learn WHAT DOES IT TOUCH? data in, effect out 6 What data it consumes, and on what basis 7 What its output does, and to whom 8 Whether a person stands between output and effect WHEN? the only fields that reach whether the entry is still true today 9 The date it was approved, and by whom 10 The date it was last reviewed, and by whom 11 The route back to a manual process, and its rehearsal date 12 The date of the next re-approval ELEVEN OF THE TWELVE CAN BE WRITTEN FROM WHAT SOMEBODY ALREADY KNOWS. FIELD 11 HAS TO BE BUILT FIRST.
Sumeru Bank Limited's twelve fields group into five questions, and the four date fields are the only ones that reach whether an entry is still true today. Field 11, the route back and its rehearsal date, is the single field that cannot be written from what somebody already knows.

Why does field 3, the named person, decide whether the other eleven are true?

Think about a shared flat where the electricity bill arrives addressed to nobody in particular. Everyone assumes somebody is paying it. The bill is a real document, correctly addressed, entirely true, and it will sit on the table until the supply is cut. A register entry with no name in field 3 behaves exactly like that bill.

The reason is not moral but mechanical. Eleven of the twelve fields are statements that go stale, and field 3 is the only field that names the person whose job it is to notice. Field 10 says the entry was last reviewed on a date; somebody has to be the one who reviews it. Field 6 says what data the use consumes; somebody has to notice when that changes. Field 11 says a route back exists; somebody has to be the one who rehearses it. Take the name away and every one of those eleven statements is still perfectly readable and nobody is late.

At Sumeru Bank Limited only 6 of the 14 uses carried a named accountable person, or 42.9 per cent. Inside the register itself the figure is better, 6 of the 9 entries and 66.7 per cent of them, and every one of the five uses the sweep found unlisted had nobody named at all. The overlap is not a coincidence and it is worth saying why. Both come from the same missing step, so a use nobody registered is a use nobody named: somebody solved a real problem and no part of the arrangement asked them to write down whose problem it now was.

AI For Finance Bootcamp — Fin Maverick

Why is field 11, the route back, the field that is always missing?

Here is the finding that says most about how registers actually get filled in. At the month 12 validation, Neelima Rao in the risk function went through the 9 registered entries and found all twelve fields complete for 2 of them, being 22.2 per cent. Field 11, the route back and the date it was last rehearsed, was absent for 7 of the 9, being 77.8 per cent.

Put those two numbers next to each other now. Together they say something neither says alone. Nine entries, two complete, so seven were incomplete. Seven were missing field 11. Field 11 was not the commonest gap in this register, it was the whole of the gap: every entry that failed to be complete, failed on that one field. Ten fields out of twelve were filled everywhere, and one field held the entire shortfall.

WHICH FIELDS WERE THERE AT THE MONTH 12 VALIDATION FIELD NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 ENTRY 1 one other the other seven entries field present field 11 absent not separately reported by the validation 9 ENTRIES LESS THE 2 COMPLETE ONES IS 7, AND 7 IS EXACTLY THE NUMBER MISSING FIELD 11. So the route back is not the commonest gap in this register. It is the whole of the gap.
At the month 12 validation, 2 of Sumeru Bank Limited's 9 entries were complete on all twelve fields and 7 were missing field 11, so the route back and its rehearsal date account for the entire shortfall rather than merely the largest part of it.

Why that field and not another? Because eleven of the twelve can be written from what somebody already knows. The use, the area it serves, the accountable person, built or bought, the data it consumes: a person can type all five answers in an afternoon from what is already in their head. Field 11 is the only field whose honest answer requires the firm to have built something first, and then to have run it while nothing was wrong. A route back that has never been rehearsed is a document, and writing a date into that field when no rehearsal happened is the one way to make a register worse than empty. So it stays blank, and the blank is the most truthful thing in the entry.

Try it out

Which field was missing from most entries at this bank, and why that one?

Breaking Into Quants Bootcamp — Fin Maverick

How to Create an AI Use Case Register from nothing?

Most firms meeting this for the first time are not maintaining a register, they are creating one from nothing, and the order they choose decides whether anybody ever uses it. There are five steps and they only work in this order.

First, a sweep for what is actually running. Nothing can be listed that has not been found, and the list a firm starts with is always shorter than the truth. Second, one line per use, in language somebody in that business area would recognise as a description of their own work. Third, a name against each line before anything else proceeds. Fourth, each line broken into its components, and the second list begins there. Fifth, and only fifth, the dates. A list with no names has nobody to ask about the components, and a list with no components has nothing to put a date against. So names come before components, and components before dates.

THE ORDER, AND WHAT STARTING AT THE WRONG END PRODUCES 1 SWEEP Find what is actually running 2 ONE LINE A USE In the words that area would use 3 A NAME ON EACH Before anything else is attempted 4 BREAK IT DOWN Each line into its own components 5 THE DATES Approved, reviewed, rehearsed, next due THE REGISTER EXISTS HERE THE INVENTORY EXISTS HERE START AT THE OTHER END INSTEAD, AND THIS IS WHAT FOLLOWS 45 component rows, none of which anybody in a business area recognises as a description of their own work, so nobody argues with it, nobody corrects it, and every row still needs a use to sit under before it means anything at all. The catalogue is finished and the register has not been started. The shorter list is the one people can recognise and argue with, which is exactly why it goes first.
Building the two artefacts has a fixed order at Sumeru Bank Limited: sweep, one line per use, a name on every line, then components, then dates. Starting with components produces 45 rows nobody recognises as their own work and no register at all.
Try it out

Starting from nothing: does the register or the inventory come first?

How to Build an AI Model Inventory underneath it, and which comes first?

The inventory is built downward from the register, one entry at a time, and the question asked of each entry is simply this: what are the separate things inside this that could be changed on their own? The test is worth stating carefully. No other wording produces a stable component count. Not what could be described separately, and not what a supplier calls a product. A component is whatever could be changed on its own, on a Tuesday afternoon, without anything else in the chain being touched.

Applied to entry 1 that test gives nine rows, and every one of them earns its row: the identity match step, the liveness check, the document classifier, the field reading step, the income corroboration rules, the scoring model, the fraud rules, the drafting assistant and the workflow router. Each row carries a description of the component, whether it learns from data or was written by somebody, and where it runs. At Sumeru Bank Limited the whole exercise came to 45 rows across the 14 entries. The inventory answers what is running and the register answers what it is for, and the reason to build them in that order is that only the shorter list can be argued with by the people who would notice if it were wrong.

One warning about the count itself. Forty five is not a measure of how much a firm is doing, and reading it as one is how inventories become competitions. A firm that writes down every rule separately and a firm that groups them will produce very different counts for identical work. The number is genuinely for the ratio: 45 over 14 is 3.2, and a ratio near 1.0 means somebody has quietly written a component list and put a register heading on it.

How complete is a register on the day it is signed off?

Completeness on sign-off day is the question almost nobody asks, and it decides whether either list is worth keeping. Sumeru Bank Limited signed off its register in month 6 holding 9 entries. In month 10, Ashok Pillai in technology risk ran a sweep and found 14 uses actually running. Every one of the five the sweep added had already been running on the day the register was signed. So the register was 64.3 per cent complete on its own sign-off day.

Hold on to why that reading is the useful one. CompletenessEntries held against uses found by a sweep, measured on a stated day. measured on any later date mixes two entirely different problems: things the firm never found, and things that have started since. On day one nothing has had time to appear, so day one completeness is the only reading that isolates discovery. Every reading after it is discovery and decay added together, and a number made of two things moving in the same direction does not show which one to fix.

And 64.3 per cent on sign-off day is an ordinary finding, not a scandal. The figure is what a first attempt looks like at a mid-sized firm where several business areas solved several problems in the same year. The bank did not conceal anything, the sweep worked, and the number went to 14 of 14 four months later. A register that claimed 100 per cent on day one without a sweep behind it would be the finding worth worrying about.

WHAT THE COMPLETENESS NUMBER DID, MONTH 6 TO MONTH 12 100 per cent 64.3 +35.7 100.0 -12.5 87.5 MONTH 6 signed off, 9 of 14 MONTH 10 the sweep lists 5 more MONTH 10 14 of 14 MONTHS 11 TO 12 2 new uses start MONTH 12 14 of 16 The five the sweep added were already running on sign-off day, so the first bar measures discovery and the last measures decay.
Sumeru Bank Limited's register read 64.3 per cent on the day it was signed, 100 per cent when the month 10 sweep closed, and 87.5 per cent two months later at 14 of 16. The first reading measures what was never found and the last measures what has started since.
Try it out

Why measure completeness on the day of sign-off rather than a year later?

How fast does a register stop being true once it is signed?

One rate decides everything here, and at Sumeru Bank Limited that rate is its own observation rather than anybody's law: about one new use case starts every month. Where the figure comes from is plain. Two new uses appeared between the month 10 sweep and the month 12 validation, and the register read 14 of 16 and 87.5 per cent on that later date.

Now the arithmetic, and it is worth doing slowly because the shape of the answer is not obvious. The moment a sweep closes, the register carries zero unlisted uses. One month later it carries one. Six months later it carries six. So across an interval of m months it carries m over 2 unlisted uses on average, and m unlisted uses on the very last day. The interval gives two different completeness figures for the same firm: an average of 14 over 14 plus m over 2, and a worst reading of 14 over 14 plus m. The decayThe fall in completeness between one sweep and the next, driven by the rate at which new uses start. is not a slow drift discovered later, it is fixed the moment somebody chooses the interval, and it can be worked out before a single sweep is ever run.

Try it out

Before the control below moves: a firm sweeps once a year and one new use starts a month. What is the average completeness across the year?

Play with it

Move the sweep interval, and watch the two readings separate

One control: the number of months between one deliberate search for unlisted uses and the next. Two consequences redraw on the same scale, the average completeness across the interval and the worst reading on the day before the next sweep, and a third marker moves with them to show the identity. The default is twelve months, the interval a firm schedules without thinking about it: an average of 70.0 per cent and a worst reading of 53.8 per cent, so a register described all year as reliable is right about half of the uses on its worst day. At six months the same two readings are 82.4 per cent and 70.0 per cent. The lime marker moves with the control: it sits at twice the chosen interval on the average line and it never leaves the height of that interval's own worst reading.

1 month12 months between sweeps24 months
THE INTERVAL DECIDES BOTH NUMBERS BEFORE ANY SWEEP IS RUN 100 80 60 40 20 COMPLETENESS, PER CENT 70.0 average 53.8 on the worst day the same figure, quoted as an average at 24 months 12 months 0 12 24 36 48 MONTHS BETWEEN ONE SWEEP AND THE NEXT AVERAGE ACROSS THE INTERVAL 70.0 THE DAY BEFORE THE NEXT SWEEP 53.8
Average completeness
70.0%
On the worst day
53.8%
Unlisted uses by then
12

Educational illustration. Figures are the invented bank's own and describe one deployment. Held constant: 14 listed uses at the close of a sweep, and one new use starting a month, an observed rate at Sumeru Bank Limited rather than a law about firms. A firm where uses start faster decays faster on exactly the same shape of curve. The intervals offered here are choices a firm makes, not anything required of anybody.

Hypothesis Testing — free micro-course from Fin Maverick

How is a sweep interval chosen, and what are its two readings?

A sweep intervalThe number of months between one deliberate search for unlisted uses and the next. is a decision, and like every decision it has a price. Sweeping monthly costs somebody a week of work twelve times a year and holds the register near 96.6 per cent on average. Sweeping every two years costs almost nothing and holds it at 53.8 per cent on average. Neither is right or wrong in itself; what matters is that the firm knows which number it has bought.

The trap is that every interval produces two numbers, not one, and firms quote the flattering one. At twelve months the average reading is 70.0 per cent and the reading on the day before the next sweep is 53.8 per cent. An auditor arriving unannounced does not sample the average; they see whatever the register is on the day they walk in, and one day in every interval is the worst one.

Now the part worth sitting with, and it is exact rather than approximate. The worst reading at any interval is exactly the average reading at twice that interval. At six months the worst is 70.0 per cent, the average at twelve. At twelve months the worst is 53.8 per cent, the average at twenty four. The two expressions are literally the same: 14 over 14 plus m, and 14 over 14 plus 2m over 2. So a firm quoting its average completeness is quoting the bad-day figure of a firm that sweeps half as often. Say that out loud in a room where somebody has just presented an average and watch what happens.

THE SAME CURVE, READ TWICE: AVERAGE AGAINST WORST DAY 100 80 60 40 20 COMPLETENESS, PER CENT 70.0 BOTH ENDS 53.8 BOTH ENDS 64.3 per cent, the sign-off day reading, which lies on neither curve the month 12 validation, 14 of 16 and 87.5 per cent, being the reading two months after a sweep closed average across the interval the day before the next sweep 0 6 12 24 36 48 MONTHS BETWEEN ONE SWEEP AND THE NEXT A FIRM QUOTING ITS AVERAGE IS QUOTING THE BAD-DAY FIGURE OF A FIRM THAT SWEEPS HALF AS OFTEN.
The green curve is the average completeness across an interval and the red curve is the reading on the day before the next sweep, and the lime connectors show the two are the same number at m and at twice m: 70.0 per cent is the worst day at six months and the average at twelve.
India

Who asks a firm what it is running, and where the answer is written down

The expectation that a regulated lender can say what it is running and who is accountable for it sits with the Reserve Bank of India, published at rbi.org.in, and where the deployer is a market intermediary rather than a bank the equivalent position is stated by the Securities and Exchange Board of India at sebi.gov.in. The accountability of a board and its officers for records of this kind is a matter for the Ministry of Corporate Affairs at mca.gov.in. The review frequencies, thresholds, field lists and effective dates shown are this invented bank's own drafting rather than anybody's requirement, and the sweep intervals on the control above are choices it could make rather than anything asked of it. Read the current position at the named sites before acting on any of it.

Try it out

A firm quotes its average completeness at a six month sweep interval. What number is that, and whose bad day is it?

Hypothesis Testing teaches you to run a test, say what it can and cannot support, and recognise a manufactured result.

What does a complete register still fail to say?

Four months after sign-off this register reached 14 of 14. Every use listed, the count perfect, the exercise apparently finished. Read what the same sweep found inside the oldest entry on the list.

The register said present and correct for three months while the thing it described had changed

Entry 1 carried a named accountable person and, by the month 12 validation, every one of its twelve fields. Entry 1 was one of the two complete entries. Inside it, in month 7, the waiting time before escalation in one of the written components had been changed, with no approval recorded and no note made anywhere. The month 10 sweep found it. For the three months in between, the register counted that entry as present and correct while the chain it described had quietly stopped matching what was approved.

Completeness measures whether uses are listed. Completeness says nothing whatever about whether a listed use is still what its entry says it is. Only two of the twelve fields even reach that question: field 10, the date it was last reviewed, and field 12, the date of the next re-approvalThe date on which an entry must be looked at again or the use retired.. No re-approval date was set when the use was approved in month 0, so field 12 on this entry had been empty ever since. The month 12 validation finally set one. So through the whole window in which the change sat unrecorded, nothing in the record was ever going to ask the question. A register can be complete, named, filled in and wrong at the same time, and the only defence against that is a date that forces somebody to look again.

Try it out

A register reads 14 of 14. What can still be wrong?

How does anybody actually use two lists at once?

In practice people use the two lists differently from the way a policy says they do. There are two doors into the pair, and which door somebody comes through decides which list they need first.

Somebody arrives with a question about approval: was this allowed, who agreed to it, on what basis. Anybody with that question comes in through the register, finds the line, reads field 3 and field 9, and goes downward into the inventory only to find out which components sit inside the use. Somebody else arrives because a component has stopped behaving: a step is returning results nobody expected, or a supplier has had an outage. The second person comes in through the inventory, finds the row, and travels upward to the entry to find out what business it affects and whose telephone rings. The register is entered from the top by anybody asking whether something should exist, and the inventory is entered from the bottom by anybody dealing with something that already does. A firm holding only one list has locked one of those two doors.

The third use is the one that changes how a board reads the list. A register line carries no sense of size, and it should. At Sumeru Bank Limited, entry 1 sits above a chain that cost an invented Rs 2,40,00,000/- to build once and Rs 65,00,000/- a year to run. Another line on the same list is a calculation somebody built inside a spreadsheet in an afternoon. Both are one line. Both are equally entitled to a name in field 3 and a date in field 12. A board member reading fourteen identical lines has no way to know that one of them holds 20.0 per cent of every component the firm runs. The ratio of 45 over 14 is worth setting alongside the register for exactly that reason.

How unregistered uses are found is set out under shadow AI, and what a named accountable person is actually accountable for is set out under the model owner. How a supplier of a bought component is assessed is set out under the AI vendor, where the data a use consumes is allowed to sit under data residency, and how a number is traced back through the steps that produced it under data lineage and master data. How the scoping test that decides what belongs on the list is worded, and the discipline of validating, challenging and re-testing a fitted component, are each covered separately.
Financial Analyst Program Bootcamp — Fin Maverick

Sources

SourceDocumentSite
Reserve Bank of IndiaPublished expectations on a regulated lender covering outsourcing, digital lending, data, consent and record keeping, the place where any expectation about what a lender must be able to say it is running is statedrbi.org.in
Securities and Exchange Board of IndiaThe equivalent published position where the deployer of a chain of this kind is a market intermediary rather than a banksebi.gov.in
Ministry of Corporate AffairsThe accountability of a board and of its officers for the records a firm keeps, the layer a named accountable person inside a firm ultimately reports intomca.gov.in
Bank for International SettlementsThe international standard on governance of deployed systems at a bank, being the origin of the expectation rather than the position in Indiabis.org

Sumeru Bank Limited, Revathi Balan, Neelima Rao and Ashok Pillai are invented.
Educational material. Not advice on any investment, tax, budget or market position.

← PreviousNext →
Fin Maverick Micro CoursesExplore Micro Courses
Fin Maverick BootcampsExplore Bootcamps
Fin Maverick

Finance education that ends in a job, not a certificate that gathers dust. Built for young India.

LEARN
CalculatorsFrameworksComparisonsCareersShowdown
RESOURCES
All CoursesMicro CoursesBootcampsInternships
COMPANY
AboutJob openingPartnership
LEGAL
Privacy PolicyTerms & ConditionsContent LicenseReturn & Refund Policy
© 2026 FIN MAVERICK / BUILT FOR INDIA.DO FINANCE, DO NOT JUST READ ABOUT IT.