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 For Finance · CoreTrack
1AI, Automation & Digital Finance
iAI Foundations
Artificial Intelligence in FinanceAlgorithmNeural Networks and Deep LearningMachine LearningArtificial Intelligence vs Machine…Computer Vision in FinanceTraining Data and LabelsNatural Language Processing in Finance
iiGenerative AI
Generative AIGenerative AI vs Predictive AILarge Language ModelsEmbeddingsHallucinationFine TuningPrompting vs Fine TuningThe PromptThe Context WindowTool CallingGroundingVector DatabasesRetrieval Augmented GenerationRAG vs Fine Tuning
iiiAutomation and Workflow
Workflow AutomationAutomation vs AugmentationHow to Map a…Straight-Through Processing and Exception…Robotic Process AutomationRule EnginesMachine Learning vs Rule-Based…
ivDocument 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
vCustomer 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
viCredit 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…
viiGovernance, 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
viiiModel 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…

Rule Engines: Encoding Decisions That Must Be Explainable

A rule engine holds the rules of a decision as readable statements, separately from the software that runs them, so the rules can be read, changed and argued with by people who do not write software. Holding the rules apart from the software is the whole point. A decision somebody will have to explain belongs in a rule engine for that reason alone, and the cost of one is keeping every statement in it true at the same time.

Notice what is not in that answer. Nothing about speed, nothing about how many decisions a second, nothing about whether a machine follows the statements better than a person would. Anything can follow rules. The value of a rule engine is not that the rules get followed, it is that the rules exist as a document somebody can point at. A rule engine is a filing arrangement rather than a technology. Keeping the arrangement honest has a cost, and the cost is the part nobody budgets for.

What is a rule engine, and how is it different from rules written into software?

Consider the schedule of charges pinned behind the counter at a small co-operative society office. Three things are going on at once and they are easy to confuse. There is the schedule itself, a printed sheet with numbered items and a dated amendment slip stuck below it. There is the clerk, who reads the sheet and applies it to whoever is standing at the counter. And there is the register in the drawer recording that item four was amended on such a date, by whom, and what it said before. Take away the sheet and the clerk still gives an answer, but now the schedule is whatever the clerk remembers, and there is nothing to argue with.

A rule engineAn arrangement where the rules of a decision are held as readable statements apart from the software that applies them. is that arrangement, built in software. The statements sit in one place as ordinary readable sentences. The software that reads them and applies them to a case sits somewhere else and is deliberately general, knowing nothing about lending in particular. The change recordThe log of who altered a statement, when, what it said before, and who approved the alteration. sits in a third place. Rules written into software are not less correct and not slower; they are simply not separable, so there is no sheet to hand anybody.

THREE THINGS THAT ARE USUALLY ONE THING 1. THE STATEMENTS 17. Allowed gap: 10 per cent 18. If the gap exceeds the allowed gap, route the file 19. Otherwise pass the file Readable by anybody. Edited without rebuilding anything. 2. THE SOFTWARE Reads the statements in order, tests the case against each, carries out the action. Knows nothing about lending. Unchanged when a statement is edited. reads 3. THE CHANGE RECORD Line 17 set to 10 per cent Before: no earlier version When: before go-live Approved: head of retail credit Not inside the statements. Kept, or not kept, by people. A REVIEWER, A COMPLAINTS DESK AND A SUPERVISOR NEED PANELS 1 AND 3. None of the three ever opens panel 2, which is exactly why the arrangement was chosen.
The statements sit in one place, the software that applies them in another, and the record of who changed what in a third. A reviewer, a complaints desk and a supervisor only ever need the first and the third, and none of them can read the second.
Try it out

What makes a rule engine different from rules written into software?

Why is that separation the whole of the value?

Because of what it does to an argument. When the rules are inside the software, a disagreement about an outcome has nowhere to land: the person who is unhappy talks to somebody at a counter, who talks to somebody in an office, who eventually asks somebody technical how the software behaves, and the answer comes back as a description rather than as a text. Every step of that chain is a retelling. When the rules are a document, the disagreement lands on a numbered line, and everybody in the argument is looking at the same twenty words.

Three separate people need that document, and none of them writes software. The person answering a complaint needs to say which line acted on this file and what it said. The person reviewing the arrangement needs to read the whole rule setThe collection of statements governing one decision, read from the first line to the last. and form a view on whether it says what the institution meant. The supervisor of a regulated lender needs to be shown, on request, how an outcome was arrived at. A rule engine hands all three of them the same object.

There is a second consequence and it is more practical. Changing a rule stops being a software change. Editing line seventeen is an afternoon, with a review and a record around it, and nothing else in the arrangement moves. The separation is why an explainable decisionOne where somebody can be shown the reasoning that produced their particular outcome, and can check it. and a quickly changeable decision tend to arrive together: they are two effects of the same filing choice.

Where does a decision that must be explained belong?

Two questions place it, and neither of them is about how difficult or how clever the decision is. The first: can the correct outcome be stated in advance? Not guessed at, not usually right, but written down before the case arrives, in a form that lets anybody holding the statement predict the answer. The second: will somebody have to explain one outcome to the person it was about? Two yeses put the decision in a rule engine, and the second yes is the one that settles it.

Run the pair over a lending chain and the answers separate quickly. Whether a declared income is close enough to a corroborated one can be stated in advance, because it is a position the lender is taking rather than a fact waiting in data, and the applicant is owed a reason. Two yeses. Which kind of document an image is cannot be stated in advance in any usable way, because employers format their paperwork four hundred different ways, and nobody outside the system ever sees that answer on its own. Two noes.

TWO QUESTIONS, AND NEITHER IS ABOUT HOW CLEVER THE DECISION IS QUESTION ONE Can the correct outcome be stated in advance? NO NOT A RULE ENGINE There is nothing to write down. It may not be a machine either. YES QUESTION TWO Must somebody explain one outcome to the person it was about? NO EITHER WILL DO Choose on cost and speed. Nothing is owed to anybody. A RULE ENGINE Two yeses, and the second one is what settles it. YES Neither question mentions difficulty or volume. A short decision can need a rule engine, and a hard one may not.
Can the correct outcome be stated in advance, and will somebody have to explain one outcome to the person it was about? Two yeses put the decision in a rule engine, and neither question is about how clever or how difficult the decision is.
AI For Finance Bootcamp — Fin Maverick

What do four real rule sets look like, and how many lines is that?

Abstraction runs out quickly here, so take a real arrangement. The retail intake chain at Sumeru Bank Limited, invented, holds nine separately built components, and four of them are procedures somebody wrote: the identity match, the income corroboration step, the fraud rules that run on the servicing book, and the workflow router that decides where every file goes next. Between them those four hold 126 lines. Not a thousand, not ten. A hundred and twenty six numbered statements decide fifteen point eight per cent of the month's outcomes.

Written componentLinesPairs to checkWorking days at 400 pairs a dayOutcomes it determined in the month
Component 1, the identity match9360.1189
Component 9, the workflow router222310.6112
Component 5, income corroboration345611.4602
Component 7, the fraud rules611,8304.6452
All four, checked set by set1262,6586.61,355

Across the rows, something awkward appears before maintenance has even entered the picture. The fraud rules are the largest set by a distance, at 61 lines, and they cost more to keep true than the other three put together. The fraud rules determined 452 outcomes. The identity match is nine lines, costs almost nothing to check, and determined 189. The size of a rule set has no particular relationship to how much of the month it decides. Anybody about to propose more lines should know that first.

THE LINES GROW GENTLY. THE CHECKING DOES NOT. COMPONENT LINES PAIRS TO CHECK 1 identity match 9 36 9 workflow router 22 231 5 income corroboration 34 561 7 fraud rules 61 1,830 From 34 lines to 61 is not quite double the lines. From 561 pairs to 1,830 is more than three times the work.
34 lines make 561 pairs to check and 61 lines make 1,830, so not quite twice the lines is more than three times the work. The fraud rules alone cost more to keep true than the other three written components put together.
Try it out

How many lines do the four written components hold between them?

What does keeping a rule set true actually cost?

Here is the thing people get wrong about maintaining written rules, and it is not laziness. Everybody understands that each line has to be right. A rule set sinks on a different point: every line has to be right at the same time as every other line. A statement that is perfectly sensible read on its own can be nonsense read against line forty. So the maintenance job is not reading 126 lines. The job is comparing them.

The comparison has a name and an arithmetic. A pair checkComparing every statement in a rule set against every other, to find two that could give different answers to one case. takes every line and holds it against every other line, asking whether there is any case both could catch and, if so, whether they agree. Each pair is looked at once and a line is not compared with itself, so for a set of n lines the count is n times n less one, divided by two. Nine lines make 36 pairs. Twenty two lines make 231. Thirty four make 561. Sixty one make 1,830.

The rules grow in a straight line and the checking grows as the square. A rule set everybody agreed was reasonable at thirty lines is unmaintainable at a hundred, and nobody noticed the moment it happened. The other way round is the version worth carrying: doubling the lines quadruples the checking. Not double. Four times.

PAIRS TO CHECK, AGAINST LINES IN THE RULE SET 8,400 6,300 4,200 2,100 0 if checking grew in step with the lines, 126 lines would be 2,079 pairs 561 1,830 7,875 pairs all 126 lines as one set 9 22 34 61 126 Lines in the rule set. The four marked below the axis are the four written components at the invented bank. The curve leaves the dashed line behind The two agree at 34 lines by construction. By 126 lines the real figure is 7,875 against 2,079, nearly four times as much.
Checking grows as the square of the lines, so the curve leaves behind a straight line calibrated to agree with it at 34 lines. At 126 lines the real pair count is 7,875 against the 2,079 that in step growth would give, which is nearly four times as much work as the intuition expects.
Try it out

Before the control below is moved: a rule set doubles from 30 lines to 60. How much more checking is that?

Play with it

Grow the rule set, and watch the checking grow twice as fast

One control: the number of lines in a rule set, from 5 to 130. One consequence: the pairs that have to be compared to keep the set free of contradiction, drawn as a square whose shaded half is the answer, with a bar for the working days it implies. The dashed outline is the same rule set at double the lines, so the quadrupling is visible rather than taken on trust. The default is the income corroboration rule at 34 lines, giving 561 pairs and about 1.4 working days at the bank's own rate of 400 pairs a day. All four sets treated as one set of 126 lines give 7,875 pairs and about 19.7 working days.

5 lines34 lines130 lines
EVERY LINE AGAINST EVERY OTHER LINE WHAT THAT COSTS IN WORKING DAYS at double the lines 2,278 pairs Each side of the square is the rule set. The shaded half above the diagonal is every pair, counted once. The diagonal is a line against itself. 5 10 15 20 Working days, at the bank's own rate of 400 pairs a day. 1.4 working days All four written sets treated as one set of 126 lines: 7,875 pairs, about 19.7 working days A real check uses the shape of the rule set to skip pairs that cannot interact, so this is the thorough version rather than the usual one.
Lines in the set
34
Pairs to check
561
Working days
1.4

A rule set of 34 lines makes 561 pairs to check, which is about 1.4 working days at 400 pairs a day. Doubling it to 68 lines would make 2,278 pairs, about 4.1 times as many.

Educational illustration. The line counts, the finding of 9 lines in 126 and the rate of 400 pairs a working day all belong to Sumeru Bank Limited, invented, and describe one deployment rather than lending in general. Every line is compared against every other here, which is the thorough version of the check; a real check uses the structure of the rule set to skip pairs that cannot interact, so a working figure would be lower. No authority publishes a threshold for the size of a rule set or a rate at which one should be checked.

Move it once and the shape of the problem is obvious in a way no table makes it. At the left the shaded triangle is almost invisible: nine lines is 36 pairs and half a morning. Push past sixty and the triangle starts eating the panel. The unpleasant part is that nothing announces itself on the way. Every individual line that got added was reasonable, small and well argued, and the total cost of holding the set together went up by roughly twice the current size each time somebody added one.

Which pairs does anybody actually check?

Now the arithmetic gets sharper, and this is the part that catches out people who have already understood the square. The four sets checked one at a time come to 36 plus 231 plus 561 plus 1,830 pairs, a total of 2,658, or about 6.6 working days. But the four sets are not four separate arrangements. All four act on the same file, one after another, in one chain. Treat all 126 lines as what they functionally are, one rule set governing one journey, and the pair count is 7,875.

The difference is 5,217 pairs, and those are the pairs where a line in one set is held against a line in another. Nobody is responsible for those 5,217. Each set has an author, a reviewer and a review date; the space between the sets has none of those things. Two thirds of the checking on this chain, 5,217 of 7,875 pairs, sits between the rule sets rather than inside any one of them, and between the sets is exactly where nobody is looking.

WHERE THE 7,875 PAIRS ACTUALLY SIT lines 1 to 126, across 9 22 34 61 each pair is counted once, so this half is not drawn INSIDE ONE SET: 2,658 PAIRS About 6.6 working days. Each of these sets has an author, a reviewer and a date on which it was read. BETWEEN TWO SETS: 5,217 PAIRS Two thirds of all the checking, and no set has been made responsible for it, because it belongs to none of them and to the chain as a whole. 2,658 inside plus 5,217 between = 7,875 pairs in the chain The four sets act on the same file one after another, so functionally they are one rule set of 126 lines. Bands are the four written components, in the order 9, 22, 34 and 61 lines. Areas are drawn to the actual pair counts.
Checked set by set, the four written components make 2,658 pairs and about 6.6 working days. Treated as the single rule set of 126 lines they functionally are, they make 7,875 pairs, and the extra 5,217 sit between the sets where no author, reviewer or review date has ever been assigned.
Try it out

Four rule sets are each checked carefully on their own. Which pairs has nobody looked at?

Breaking Into Quants Bootcamp — Fin Maverick

How do rules contradict each other?

Two shapes, and they look nothing alike. The first is a contradictionTwo statements that would give different answers to the same case.: two lines that both catch the same case and disagree about what to do with it. A file arrives holding a missing corroborated income and a long customer history, one line says route it and another says pass it, and which of them acts depends on which comes first in the document. Nobody wrote that ordering as a decision. The ordering is a decision all the same, and it is now the rule.

The second is an unreachable lineA statement no case can ever reach, because an earlier statement always catches the case first.: an earlier line always gets there first, so nothing ever reaches it. Somebody wrote a careful test for gaps above twice the allowed gap, meaning to mark those files for a closer look, and put it below the line that routes everything above the allowed gap. Every file that would have reached it was already caught. The statement is in the document, it reads perfectly, and it has never once run.

TWO WAYS A RULE SET GOES WRONG, AND ONLY ONE OF THEM EVER SHOWS UP A CONTRADICTION Line 12: if the corroborated income is missing, route Line 26: if the customer history is long enough, pass One file matches both. Two answers exist for it. THE FILE route pass FOUND WHEN THE CASE ARRIVES It produces an outcome somebody can disagree with. AN UNREACHABLE LINE Line 18: if the gap is above the allowed gap, route Line 21: if the gap is above twice the allowed gap, mark Line 18 already caught every case line 21 wanted. THE FILE route, always at line 18 NEVER FOUND FROM BEHAVIOUR It produces nothing at all, so there is nothing to notice. ONE IS FOUND BY WATCHING THE SYSTEM. THE OTHER IS ONLY FOUND BY READING IT. Line numbers here are illustrative and show the shape each fault takes rather than a particular statement at the invented bank.
A contradiction gives two answers to one case and shows up when the case arrives; an unreachable line gives no answer to any case and never shows up at all. Only one of the two can be found by watching what the system does.
Try it out

A line in a rule set can never be reached. When does that come to light?

Financial Analyst Program Bootcamp — Fin Maverick

Why does a line nothing can reach survive for years?

At the month twelve validation of the intake chain, Neelima Rao in the risk function read all 126 lines and held them against each other. She found nine, being 7.1 per cent of the set, that either contradicted another line or could never be reached because something earlier always caught the case first. Not one of the nine had produced a wrong outcome that anybody could identify, and that is not a footnote, it is the reason they were still there.

Take the two shapes in turn and the survival makes complete sense. An unreachable line produces nothing: no outcome, no complaint, no alert, no entry in any report. There is no signal for anybody to miss, because there is no signal. A contradiction produces an outcome, but it produces a perfectly ordinary looking one, decided by whichever line happens to sit higher in the document. Somebody who is unhappy with it is unhappy with the outcome, not with the fact that a second line existed that would have said something else.

Nine lines in 126 on a rule set that has been edited by several people over a year is an ordinary finding, and reading it as a scandal is the wrong reading twice over. A pair check exists for exactly that, and a maintained rule set that had never been checked would be more likely to hide more. The uncomfortable version is not that the bank found nine, it is that a rule set which has never had a pair check has an unknown number and no way to say so.

126 WRITTEN LINES, AND THE 9 THAT ONLY A READING COULD FIND 9 LINES 7.1 per cent 117 LINES 92.9 per cent None of the nine had produced a wrong outcome anybody could identify. That is why they lasted. The nine are shown scattered. The validation reported them as one count across all four sets and did not split them by set, so no position here should be read as a claim about which component held which fault. A rule set that has never had a pair check has an unknown number here, not a zero.
9 of 126 lines, being 7.1 per cent, contradicted another line or could never be reached, and not one of them had produced an identifiable wrong outcome. That silence is the reason they survived, and it is an ordinary finding on a rule set that gets edited and then read.

What does the change record have to carry?

A statement on its own answers one question: what the rule says today. The statement does not answer why it says that, who decided it should, or what it said last year. A complaint, a review and a supervisor ask exactly those three questions, and none of them is answerable from the document. The answers come only from the record kept beside the statement, and the record has to carry four things: who changed the lineOne statement in a rule set, testable on its own, usually numbered so it can be cited., when, what it said before, and who approved that.

Take the tolerance line inside the income corroboration rule, the one holding the allowed gap of 10 per cent. The allowed gap decides whether an applicant declaring Rs 45,000/- a month against a corroborated Rs 38,000/- gets an answer in four minutes or waits two working days. The line itself states that the figure is 10 per cent. The record beside it states that 10 per cent is a choice the bank made, that it has not been changed since it was written, and which post signed it off. The line explains what happens; only the record explains why, and why is what the person affected is asking.

ONE LINE, AND THE FOUR THINGS THAT HAVE TO SIT BESIDE IT INCOME CORROBORATION RULE, LINE 17 OF 34 THE CONDITION If the declared monthly income exceeds the corroborated monthly income by more than the allowed gap of 10 per cent THE ACTION Route the file to the exception desk Everything the document can state ends here. THE CHANGE RECORD, KEPT SOMEWHERE ELSE 1 WHO CHANGED IT Written once, before go-live. Never edited since. 2 WHEN Month 0, when the use case was approved. 3 WHAT IT SAID BEFORE No earlier version. This is the first. 4 WHO APPROVED IT The head of retail credit. This is the record of the rule. The record of what happened to one particular file is a separate thing and is covered elsewhere.
The line states the condition and the action, and beside it sit who last changed it, when, what it said before and who approved that. The document answers what the rule is; only the four fields beside it answer why it says that and who decided it should.

The change that had no record, and what three months of it cost

In month 7 one line of the 22 in the workflow router was edited: the waiting time a file sits for before it escalates. Nobody sought approval and nobody wrote down what the line had said before, and here is the awkward part. Neither omission broke any policy. The scope the bank had written at that point did not reach the router at all, so nothing required an approval and nothing required a record.

The edit was found in month 10, by a sweep that Ashok Pillai in technology risk was running to answer a different question entirely. The edit itself was sensible and nobody has suggested otherwise.

The cost was three months in which the bank was running the one arrangement it had chosen specifically so that decisions could be explained, applying a line nobody could account for. A rule engine supplies the ability to explain a decision. A rule engine does not supply the record, and a rule set without a change record is a component that cannot be read, with extra steps.

A READABLE RULE, AND THREE MONTHS OF NOT BEING ABLE TO ACCOUNT FOR IT THREE MONTHS, NOBODY COULD ACCOUNT FOR IT month 4 go-live month 7 Router line edited: the waiting time before a file escalates Approved by: not recorded Previous value: not recorded month 10 A sweep looking for something else finds the edit Not found by anything watching month 12 validation Nothing about the edit broke a policy: the scope the bank had written did not reach the router, so no approval and no record was required of anybody. The line stayed perfectly readable throughout. What went missing was the answer to who decided it, and why.
One line of the router was changed in month 7 with no approval and no record, breaking no policy, and for three months the bank could not account for a rule it was applying to every file. Readability survived the whole episode; only the record was missing, and the record is the half that answers why.
Try it out

A rule engine is running a line nobody can account for. What has been lost?

Debt Capital Markets Bootcamp — Fin Maverick

When does a rule set stop being the explainable option?

Long before it stops working, and that is the awkward finding. Neelima Rao read the 34 lines of the income corroboration rule end to end in 25 minutes. Hold that rate and 126 lines is about 93 minutes, an hour and a half of somebody's day. The set still works. Every line is still readable. But nobody is going to spend an hour and a half to answer one customer asking why their application was routed, and if the honest answer to a complaint is here are 126 lines, the arrangement has quietly stopped delivering the explanation it was chosen for.

Past a certain size a rule set is auditable but no longer readable, and the two are not the same duty. Auditable means somebody can, given time and a reason, read the whole thing and form a view. Readable, in the sense a complaints desk needs, means the reason a particular file got a particular outcome can be produced now, in a sentence. The second does not follow from the first, and it does not arrive by itself. Something has to be built that reports which line acted on this file, quotes it, and stops.

TWO WAYS TO EXPLAIN THE SAME OUTCOME BY SHOWING THE RULES 126 LINES about 93 minutes at the rate one reviewer read 34 lines in 25 minutes Answers every question except the one asked. BY PRODUCING THE LINE THAT ACTED Line 17 acted on this file: the gap was 15.6 per cent seconds one line, quoted, with its record Has to be built. It does not arrive with the rule engine. Past a certain size a rule set is auditable but not readable, and only one of those two answers a customer.
Nobody reads 126 lines to answer one customer question, so past a certain size the explanation has to be produced from the rules rather than by showing them. The reading time is arithmetic on one reviewer's rate of 34 lines in 25 minutes, at the invented bank.
Try it out

126 lines govern a decision. Is that still explainable?

Regression for Finance — free micro-course from Fin Maverick

Where is a rule engine the wrong tool?

Go back to the first of the two placing questions and take a no seriously. Where nobody can state the correct outcome in advance, there is nothing to write down, and putting the step in a rule engine produces a document full of statements that are approximately true and gradually acquire exceptions until nobody can read them. Deciding which kind of document an image is, is the clean example: four hundred employers format their paperwork four hundred ways, and no set of written statements survives contact with the four hundred and first.

People get the next move wrong, not the first one. A no to the first question does not automatically hand the step to something fitted to data. A no may mean the step belongs with a person, and on the eleven step retail process at the invented bank exactly that happened: the step where the assessment is written was left with people, not because nobody had thought about it, but because nobody could say in advance what the right assessment was. Reaching for a component that learns from examples at that point answers a different question from the one that was asked.

There is a second wrong fit that is less obvious. A rule engine is the wrong tool where a decision genuinely changes every week. The change record and the pair check then cost more than the decision is worth. If the statements have to be rewritten faster than anybody can hold them against each other, the arrangement has stopped being a document and become a rolling argument, and the cost of the filing is being paid without the benefit arriving.

Try it out

The correct outcome for a step cannot be stated in advance. Rule engine?

Regression for Finance teaches you to fit a regression, read the diagnostics, and know when the result is meaningless. Writing an Investment Thesis — free micro-course from Fin Maverick

How does a reviewer, a complaints desk or a supervisor use this?

What each of them actually does with it

A reviewer uses the pair arithmetic to size the work before agreeing to it. Asked to give an opinion on whether four rule sets are internally consistent, the honest scoping answer is 2,658 pairs and about 6.6 working days if the sets are taken one at a time, and 7,875 pairs and about 19.7 working days if they are taken as the single set they functionally are. The two numbers are three times apart and they answer two different questions. Agreeing to the work without saying which one is being done is how a review ends up meaning less than everybody thought it did.

A complaints desk uses the change record rather than the rule. When somebody writes in about a routed file, the useful reply names the line that acted, quotes what it says, and states that the figure inside it is a choice the lender made. Naming the choice is what turns a refusal into something the applicant can argue with. Quoting the line without the record produces a reply that sounds like a law of nature, and Ismail Sheikh, who runs the exception desk, gets a second letter for every one of those.

Somebody proposing a new line uses the square. The right question to ask of any proposed addition is not whether the line is sensible. The line always is. The question is how much it adds to the total. Adding one line to the 34 line income rule adds 34 new pairs to check. Adding one to a 126 line set adds 126. A rule set gets expensive to hold together in exactly the way an address book gets expensive to keep free of duplicates: not line by line, but pair by pair.

The shape is identical at any scale, so here is a household version. A wedding caterer with four written rules about who gets which plate can hold all four in mind at once and spot instantly that two of them collide over the same guest. At forty rules, covering guests, dietary needs, the head table, children and staff, nobody can hold them all, and the contradictions do not announce themselves. The collisions just produce one confused guest at a time, and everybody assumes the confusion was that guest.

India

Who sets expectations on a lender running a rule engine?

Where a written rule decides an outcome for a borrower, the expectations on the lender sit with the Reserve Bank of India. The Reserve Bank publishes its position on digital lending, outsourcing, customer data, consent and record keeping at rbi.org.in. Where the deployer of such an arrangement is a market intermediary rather than a lender, the equivalent expectations sit with the Securities and Exchange Board of India at sebi.gov.in. The 126 lines, the 400 pairs a working day, the finding of 9 lines and the allowed gap of 10 per cent are all the invented bank's own figures and choices, and none of them corresponds to anything published by any authority. The current position is the one published at the issuing body's own site.

How a component that derives its behaviour from past data reaches its answer is set out separately, as is the test used to decide which steps of a process should be automated at all. Whether a rule set or a component fitted to data is the cheaper thing to review at a given volume of cases is a separate question and is answered separately. The record of what happened to one particular file, as against the record of changes to a rule, is a different artefact and is covered elsewhere.
The Risk Management Program bootcamp teaches you to set a limit framework and run it through a breach.

Sources

SourceDocumentSite
Reserve Bank of IndiaPublished expectations on a regulated lender covering digital lending, outsourcing, customer data, consent and record keepingrbi.org.in
Securities and Exchange Board of IndiaEquivalent expectations where the deployer of a decisioning arrangement is a market intermediarysebi.gov.in
Bank for International SettlementsInternational supervisory material on the governance of decisioning arrangements at banks, cited as the origin before what India doesbis.org

Sumeru Bank Limited, Neelima Rao, Ismail Sheikh 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.