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…

Blockchain and Distributed Ledger: The Structure and the Network Types

A distributed ledger is one record of the same facts held by several parties at once, kept in step by an agreed procedure rather than by one party sending copies to the others. A blockchain is one way of building such a record and not another name for it. The structure fixes exactly one thing: no single holder can quietly change an entry everybody else already holds.

Every question worth asking about a shared record turns out to be a question about who holds it and who may write to it, and not a question about software. Naming the holders first settles the rest: which network type this is, what it costs to agree a single entry, what the arrangement takes out of somebody's working day, and whether it was worth building at all. With the holders named wrongly, no amount of engineering rescues the idea. Parties decide more than machinery does.

What is a distributed ledger, and how is it different from an ordinary database?

A wedding fund run by five people is the whole problem in miniature, so start there. Five cousins collect contributions for a cousin's wedding and each of them keeps a small notebook. Every notebook is honest. Each cousin writes down only what passed through their own hands, and one of them writes in pencil, so every notebook is also incomplete. Two weeks before the wedding they sit down to work out what has actually come in, and the evening goes on rather longer than any of them expected. Nobody has done anything wrong. There are simply five records of one set of facts and no agreed way of putting them together.

Now change one thing. Put a single register on the table in the middle, let all five write into it in front of each other, and let none of them take it home. The facts have not changed and the money has not changed. The agreeing now happens at the moment each entry is made rather than two weeks later, so the evening's work at the end has gone.

The single register in the middle is what a distributed ledger is, and the definition is about custody and permission rather than about technology. A distributed ledgerOne record of the same facts held by several parties at once and kept in step by an agreed procedure. is one record of the same facts held by several parties at once, kept in step by a procedure all of them accepted in advance. An ordinary database is the other arrangement: one party holds the record that counts, and everybody else gets told what is in it. If the holder edits a row at four in the afternoon, the other parties find out when they are told, or when they next ask, or never.

FIVE HOLDERS, ONE RECORD, THE SAME ENTRIES ON EVERY ONE OF THEM Nobody here has a copy. Each of the five holds the record itself, which is the whole of the difference. SUMERU BANK entry 0411 settled entry 0412 settled entry 0413 settled entry 0414 settled entry 0415 pending INSTITUTION 2 entry 0411 settled entry 0412 settled entry 0413 settled entry 0414 settled entry 0415 pending INSTITUTION 3 entry 0411 settled entry 0412 settled entry 0413 settled entry 0414 settled entry 0415 pending INSTITUTION 4 entry 0411 settled entry 0412 settled entry 0413 settled entry 0414 settled entry 0415 pending INSTITUTION 5 entry 0411 settled entry 0412 settled entry 0413 settled entry 0414 settled entry 0415 pending Entry 0415 has been proposed. It is pending on all five at the same moment, and it is settled on all five at the same moment. AN ENTRY EXISTS ONCE IT IS ON ALL FIVE HOLDERS and not once one of them has written it. That single sentence is the arrangement, and everything else is detail. Sumeru Bank Limited and institutions 2 to 5 are invented, and so is every entry number shown here.
Five institutions each hold the same record, and an entry exists once it is on all five rather than once one of them has written it, which is why the definition is about holders and not about software.

A distributed ledger has no centre, and the absence matters as much as anything it has. No holder sits in the middle with arrows radiating out to the rest. Sumeru Bank Limited, an invented bank, is one of five holders and has no more standing in the record than the other four. If Sumeru rewrites entry 0413 on its own machine tonight, the other four still hold the original, and the disagreement is visible the moment anyone looks. Nothing in that protection is cryptographic. The protection is four other people in the room.

AI For Finance Bootcamp — Fin Maverick

How does a blockchain actually construct one of those records?

By grouping entries and then tying each group to the one before it. Entries are collected into a group, the group is closed, and a short value is computed from everything inside it. The resulting value is a fingerprintA short value computed from an entry or a group of entries, which changes if anything inside it changes.: change so much as a digit inside the group and the value that comes out is different. The next group then carries the previous group's fingerprint inside itself. Its own fingerprint therefore depends on the one before, and that one on the group before it, all the way back.

The school register does the same job without any of the vocabulary. In a register where each new sheet begins by copying a short code printed at the foot of the previous sheet, and where the code at the foot of each sheet is worked out from everything written on it, one attendance mark on the second sheet cannot be altered on its own. The code at the foot of the second sheet no longer comes out right, so the code copied onto the third sheet is wrong, and the fourth and the fifth are wrong after it. The change itself has not been prevented. Making the change quietly has been prevented.

A blockchainOne way of constructing a shared record, in which entries are grouped and each group carries a fingerprint of the group before it. makes an alteration visible rather than impossible, and the whole of its reputation rests on that one distinction. The chaining does not put a lock on the past. The chaining removes the possibility of editing the past without anyone noticing. For a record held by several parties, that is the property that actually matters.

EACH GROUP CARRIES A FINGERPRINT OF THE GROUP BEFORE IT NOTHING TOUCHED: EVERY GROUP MATCHES THE ONE BEFORE IT GROUP 1 3 entries inside carries: nothing before it its own: 9c41 GROUP 2 4 entries inside carries: 9c41 its own: b7e0 GROUP 3 3 entries inside carries: b7e0 its own: 2d58 GROUP 4 5 entries inside carries: 2d58 its own: f019 ONE ENTRY IN GROUP 2 IS CHANGED: EVERYTHING AFTER IT STOPS MATCHING GROUP 1 3 entries inside carries: nothing before it its own: 9c41 GROUP 2, ALTERED 4 entries, one edited carries: 9c41 its own: 6a83, not b7e0 GROUP 3, NOW WRONG 3 entries, untouched carries: b7e0, which is gone no longer matches GROUP 4, NOW WRONG 5 entries, untouched carries: 2d58, computed from a group that changed The edit was not blocked. Groups 3 and 4 were never touched and are now visibly wrong, which is how the edit announces itself. On a record held by five parties, the other four still hold the version that matches, so the disagreement has a witness as well as a signature. The fingerprint values shown are invented and stand in for far longer ones.
Change one entry in an early group and its fingerprint changes, so every group after it no longer matches, which is what makes the alteration visible rather than impossible.

Why are the two words not interchangeable?

Blockchain vs Distributed Ledger Technology, and what gets lost when the two words are swapped

A distributed ledger is the arrangement: several parties, one record, an agreed procedure for adding to it. A blockchain is one construction of that record, the one that groups entries and chains the groups together with fingerprints. Every blockchain is therefore a way of keeping a shared record. Not every shared record is a blockchain. A set of parties can agree to keep one record in step by other means entirely, and several do.

The relation is that of a building to a construction method. A load bearing wall is one way of holding a roof up. A frame is another. Somebody who uses the words wall and building as synonyms will end up unable to ask whether the roof needs holding up at all. Whether the roof needs holding up is the only question that decides anything.

The arrangement is what gets lost when the two words are used as one, and the arrangement is the part that decides whether any of this is worth doing. A room asked whether it needs a blockchain produces a debate about software. The same room asked who holds the record today, who is allowed to write to it, and how much time those parties currently spend agreeing their versions with each other settles within ten minutes into either a real case or none at all. Almost every proposal that fails, fails on the second set of questions and never reaches the first.

Try it out

Is every distributed ledger a blockchain?

Who may read and who may write, and how many kinds of network does that give?

Blockchain Network Types, the four of them, numbered

Two questions settle it. Who may read the record, and who may write to it. Each question has two answers, anyone or only named parties, so there are four combinations, and every other difference that gets talked about follows from where a given arrangement sits in that grid. The four are numbered so that a later question can point at one without ambiguity, and the numbering is a teaching device rather than anybody's official list.

FOUR TYPES, AND ONLY TWO QUESTIONS BEHIND THEM Who may read the record, and who may write to it. Everything else is a consequence of those two answers. TYPE 1 Open to read, open to write WHO MAY READ anyone at all WHO MAY WRITE anyone at all WHO HOLDS IT whoever chooses to NOT AVAILABLE TO A REGULATED LENDER TYPE 2 Open to read, named writers only WHO MAY READ anyone at all WHO MAY WRITE named parties only WHO HOLDS IT anyone who joins READERS CANNOT BE NAMED OR LIMITED TYPE 3 Named readers and named writers WHO MAY READ named parties only WHO MAY WRITE named parties only WHO HOLDS IT the named parties, under an agreement THE ONE SUMERU BANK LIMITED PILOTED TYPE 4 Held by one institution alone WHO MAY READ whoever it allows WHO MAY WRITE itself, and nobody else WHO HOLDS IT one institution NO SECOND HOLDER, SO NOTHING IS SHARED The numbering is a teaching device and is not anybody's official classification.
Open to read and write by anyone; open to read and permissioned to write; permissioned on both and shared between named institutions under an agreement; or held by one institution alone, which is a record with nobody to share it with.

Type 3 is the one with a name of its own in ordinary use. A permissionedA record where the parties who may read and write are named in advance under an agreement. arrangement is one where the parties who may read and write are named in advance, and the naming is done in a contract rather than in software. The most important part of a type 3 arrangement is therefore a document that a lawyer drafted, not a component that an engineer built.

Try it out

Which network type describes a record shared between five named institutions under an agreement, and why would a regulated lender pick that one?

Which of the four does a regulated institution actually use?

Type 3, and the reason has almost nothing to do with speed or cost. On any given day a regulated lender has to be able to answer four questions. Who holds a record containing its customers' details? In what country does that holder sit? If that holder walks away, what happens to the record? And who is accountable when something in it turns out to be wrong? On a type 1 or type 2 arrangement the set of holders is whoever turned up, and the four questions have no answers at all. None of that is a criticism of the open types. A named accountable party is a requirement of the institution, not a feature of the record.

The proposal a bank actually receives most often is type 4, a shared record it will hold entirely by itself, and type 4 is an ordinary database carrying the cost of a structure whose whole point is other holders. There is nobody to disagree with an entry, nobody holding a copy that still matches when a row is edited, and nothing to keep in step. Every property that made the arrangement worth discussing came from the other four parties in the picture, and the proposal has removed all four of them.

THE PROPOSAL THAT ARRIVES MOST OFTEN, AND WHAT IS MISSING FROM IT PROPOSAL: A SHARED RECORD FOR THE BANK'S OWN DAILY LIST Holders of the record: 1. the bank 2. 3. 4. 5. Four slots were never filled in, and nobody at the meeting asked what was supposed to go in them. PARTIES: 1 PAIRS WHO MUST AGREE: 0 One party has nobody to agree a record with. WHAT THIS ACTUALLY IS A database with extra steps. There is no second holder to keep the version that matches when a row is quietly edited tonight. There is nothing to keep in step, because there is only one of it. The cost of the structure is paid in full. None of the point of it is delivered.
A shared record held by a single institution has no second holder to disagree with it, so it carries the cost of the structure and none of its point, and the four empty holder slots are the entire finding.
Try it out

A firm proposes a shared record that it alone will hold and write to. What has it proposed?

What is a smart contract, and is it either of those two words?

Smart Contract, and why it is neither smart nor a contract

A smart contractA written rule stored on the shared record that carries itself out when a stated condition is met. is a written rule stored on the shared record that carries itself out when a stated condition is met. The definition is that short. Somebody wrote the wording. The wording sits where every holder can see it. When the condition it names becomes true, the rule runs, and it runs because running is what it does rather than because anyone decided in the moment that it should.

Most people already live with one. A standing instruction at a bank that moves Rs 5,000/- to a landlord on the fifth of every month is exactly this shape: a written rule, held somewhere neutral, that executes on a condition. The instruction will pay the landlord on the fifth of the month after the tenant moved out, and it will pay them while the tenant is asleep, and it will pay them while the tenant is arguing with them. Nobody would call that instruction clever, and nobody would take it to a court as the tenancy agreement. The instruction is automation with the word contract stuck to it.

THE STORED RULE, WRITTEN OUT IN FULL RULE 07, STORED ON THE SHARED RECORD, VISIBLE TO ALL FIVE HOLDERS IF the stated date has been reached AND the sending holder's balance is at least the amount THEN move the amount to the receiving holder ELSE do nothing, and record that nothing was done Nothing in these four lines asks whether the transfer is still wanted, or whether the person who wrote them has changed their mind. 1 A person wrote this wording. 2 Every holder can read it. 3 The condition is checked, not judged. Nobody weighs it up. 4 It runs whether or not its author still wants it to. 5 There is no cancel. There is only a further instruction. Callouts 4 and 5 are the same property as callout 2, seen from the side nobody puts in the proposal. A rule that cannot be quietly changed is also a rule that cannot be quietly stopped, and both follow from where it is stored. Rule 07 is invented and is not drawn from any deployment.
If the condition holds, move the amount: a rule somebody wrote, stored where everybody can see it, running whether or not its author still wants it to.

The property that makes a stored rule attractive and the property that makes it unforgiving are one property. The wording therefore has to be settled before it is stored rather than after. People choose this arrangement because the rule cannot be quietly rewritten by whichever party it happens to favour. The same sentence says the rule cannot be quietly stopped by whichever party it happens to hurt. One half cannot be kept without the other.

Try it out

A smart contract runs and moves an amount its author no longer wants moved. What happens?

Breaking Into Quants Bootcamp — Fin Maverick

What does the structure actually fix?

One thing, and it fits in a sentence. No single holder can quietly change an entry that everybody else already holds. The word doing the work is quietly. Read the sentence twice. A holder can absolutely change its own version. The other holders still hold what was there before, and the chaining makes the alteration announce itself, so no holder can change its own version and have the change pass unnoticed.

Everything a shared record is famous for reduces to that one sentence, and a proposal that promises anything beyond it is promising something the structure does not supply. It does not make the entries true. The structure does not make the parties honest. Nothing in it verifies that the person who sent an instruction was entitled to send it. The structure removes one specific possibility from the world, the possibility of a silent rewrite by one party, and that possibility is worth removing precisely when several parties would otherwise have to trust one of their number to hold the only copy.

Try it out

State in one sentence what a shared record actually fixes.

What does the structure leave exactly as it was?

Whether the entry was right when it was written. A shared entry proves that all the holders hold the same words. The entry does not prove that the words were true, that the person who sent them meant to send them, or that they were entitled to send them at all. The record starts working after the instruction arrives rather than before, and those three separate questions get no answer from it.

A shared record meets the consent question here, and comes off worse than people expect. A record is provable when it holds who did what, when, on what wording and under what authority. A shared record supplies the when and the what with great confidence, and it is silent about the who and the under what authority unless somebody wrote those into the entry as well. The structure guards the record against later editing and offers nothing at all about what went into it, so a wrong entry becomes a permanent wrong entry rather than a temporary one. That is not a defect. The behaviour is what the structure was built for, applied to a case it was never built to help.

Try it out

An entry on a shared record is wrong. What can the structure do about it?

What happens when something is sent wrongly on a record nobody can alter?

The remedy is a second entry that cancels the first, and both of them stay in the record forever. Anyone who has kept a cash book in ink knows the move already. The wrong figure is not scratched out. A scratched out figure is exactly what a scratched out figure looks like to whoever reads the book next. A reversing line goes underneath, and the book now carries the mistake and the correction as two permanent facts. An offsetA second entry that cancels the effect of a first one, because the first cannot be removed. is that reversing line, and on a shared record it is the only remedy available.

Sumeru Bank Limited found out what that costs in ordinary counting. Its pilot carried 1,200 instructions on a permissioned distributed ledger shared with 4 other institutions. Three of the 1,200 were sent wrongly, or 0.25 per cent. Not one of the three could be removed. Each needed a second instruction sending the amount back, so the record ended the pilot holding 1,203 entries describing 1,197 intended transfers. The instruction count and the entry count separated the moment something went wrong and they never came back together.

THREE WRONG INSTRUCTIONS BECAME SIX PERMANENT ENTRIES Sumeru Bank Limited, invented, over one pilot of 3 months on a record shared with 4 other institutions. DRAWN FAR LARGER THAN SCALE SENT: 1,200 INSTRUCTIONS 1,197 sent correctly 3 sent wrongly ADDED TO CORRECT THEM: 3 OFFSETTING INSTRUCTIONS nothing changes here, because nothing here can be reached 3 offsets THE RECORD NOW HOLDS: 1,203 ENTRIES 1,197 correct entries 1,197 intended transfers 1,203 entries in the record, and the gap never closes again The six blocks on the right are enlarged so they can be seen: at the scale of the long bar each entry is about half a pixel wide.
1,200 instructions were sent, 3 were wrong, and the record holds 1,203 entries describing 1,197 intended transfers, with the mistake and its correction sitting side by side for the life of the arrangement.

Six entries now describe three mistakes, and they will still be there in ten years. At 0.25 per cent that is not a scandal. At a rate a person would call ordinary it becomes one. On a record like this a correction never replaces anything. The correction accumulates beside the mistake, and anyone reading the record later has to work out which pairs cancel and which do not.

Financial Analyst Program Bootcamp — Fin Maverick

Where does a shared record save real work, and where does it save none at all?

Here is the test, and it costs nothing to apply. Count the parties who each keep their own record of the same events. Then count the pairs among them. A pair is where the work is: two parties, two records, one conversation to agree them. Each such conversation is a reconciliationChecking two records of the same events against each other, which needs two parties to be worth doing., and the pairs are the only thing a shared record actually removes. The pairs among a set of parties come to the number of parties times one less than that, all halved. Five parties make ten pairs. Eight make twenty eight. One party makes none. There is nobody on the other side of the table.

EACH DOT IS A PARTY KEEPING ITS OWN RECORD. EACH LINE IS A PAIR THAT HAS TO AGREE TWO OF THEM. A shared record replaces every line in a picture with a single record. At one party there are no lines to replace. 1 PARTY 2 PARTIES 3 PARTIES 5 PARTIES 8 PARTIES 0 pairs 1 pair 3 pairs 10 pairs 28 pairs nothing to remove the pilot arrangement FOUR TIMES THE PARTIES IS NOT FOUR TIMES THE WORK Going from 2 parties to 8 multiplies the parties by 4 and the pairs by 28, and a shared record replaces all 28 with one record.
Five parties keeping their own records have ten pairs to reconcile and one party has none, so a shared record removes exactly what the pairs were costing and nothing more than that.

So the decision has two questions in it and neither one is about technology. Are there several parties who each keep their own record of the same events? And do those parties currently spend real time agreeing those records with each other? If either answer is no, a shared record has no work to do in that situation, whatever else is true about it.

TWO QUESTIONS, ASKED BEFORE ANY TECHNOLOGY IS CHOSEN QUESTION 1 Do several parties each keep their own record of the same events? YES QUESTION 2 Do those parties spend real time agreeing those records with each other? YES THE ONLY CASE THAT WORKS A shared record removes exactly the work those pairs were costing. NO NO NOTHING HERE APPLIES: THE WORK TO BE REMOVED DOES NOT EXIST Sumeru Bank Limited's own daily reconciliation of 430 items stops at question 1. It runs between the bank and its own core ledger, so there is one party, no second record, and no pair. A shared record has nothing to share. The 430 item daily list is the invented bank's own figure and describes one deployment.
Are there several parties who each keep their own record of the same events, and do they currently spend real time agreeing those records: if either answer is no, a shared record has no work to do.
Try it out

Five institutions each keep their own record of the same transfers. How many pairs have to agree their records with each other?

Play with it

Add a party, and watch the lines that have to be agreed appear between them

One control: the number of parties who each keep their own record of the same events, from 1 to 12. One consequence: the pairs among them who have to agree their two records, drawn as an actual line between every two parties, against the single record a shared arrangement puts in their place. The default of 5 parties is Sumeru Bank Limited plus the 4 other institutions in its pilot, and it reads 10 pairs against 1 shared record. Move the control down to 1 party and the picture empties: 0 pairs, and nothing at all for a shared record to remove. The bank's own daily 430 item reconciliation sits in exactly that position.

EVERY LINE IS TWO PARTIES WHO HAVE TO AGREE THEIR TWO RECORDS WITH EACH OTHER A shared arrangement replaces every line in this picture with one record that all of them hold. Each numbered dot is one party keeping its own record. 5 parties, 10 lines between them PARTIES WHO EACH KEEP THEIR OWN RECORD 5 PAIRS WHO MUST AGREE THEIR TWO RECORDS 10 PAIRS TO AGREE, AGAINST ONE SHARED RECORD 10 pairs to agree 1 shared record, at every setting Both bars use the same scale, which runs to 66 pairs, the reading at 12 parties. The picture counts relationships rather than minutes, because this case measured no reconciliation time between institutions.

Parties who each keep their own record: 5

Parties
5
Pairs to agree
10
Records under a shared arrangement
1

Educational illustration. Every party is assumed to keep its own record of the same events, every pair is assumed to agree its two records with the other, and the shared arrangement is assumed to replace all of that with one record. The party count is generic; the default of 5 is the invented bank's own pilot, being Sumeru Bank Limited plus 4 other institutions. Sumeru Bank Limited built its intake chain for Rs 2,40,00,000/- once and runs it for Rs 65,00,000/- a year, and neither figure covers the pilot, so the control carries no money figure.

Try it out

A daily reconciliation runs between a bank and its own core ledger. Would a shared record help?

Fund Waterfalls and Carry — free micro-course from Fin Maverick

What did the pilot at Sumeru Bank Limited actually carry?

The pilot ran on a tokenised deposit, meaning a claim on the bank recorded as a token on the shared record, over a permissioned arrangement shared with 4 other institutions. The deposit sat on network type 3 in the numbering above. SettlementThe moment a transfer becomes final between the parties to it. between the five fell from 1 working day to under a minute. The fall is a real result and the reason the pilot is worth reading at all.

What was measuredThe reading
Holders of the record5
Network type3
Length of the pilot3 months
Instructions carried1,200
Settlement between the five, before1 working day
Settlement between the five, afterunder a minute
Instructions sent wrongly3, being 0.25 per cent
Instructions that could be removed0
Offsetting instructions needed3
Intended transfers1,197
Entries the record now holds1,203

The two ends of the table reconcile in both directions and it is worth doing the arithmetic yourself. Take the 1,200 sent, remove the 3 that were wrong, and 1,197 transfers were actually intended. Take the same 1,200 and add the 3 offsets that had to be written afterwards, and the record holds 1,203. The 6 entries between those two numbers are three mistakes and three corrections, and they are the permanent residue of the 0.25 per cent. The pilot did not go to production at Sumeru Bank Limited.

The error that gets made, and what it costs

Sumeru Bank Limited read the pilot as a settlement result, and it was one. Settlement between five institutions fell from a working day to under a minute and nobody has to apologise for that. The bank did not read the 1,203 against the 1,197. A record nobody can alter is not a record that is always right; it is a record whose mistakes stay visible for good, and the correction sits beside the mistake for the life of the arrangement rather than replacing it. Anybody reading the record in five years has to work out for themselves which entries cancel which.

The second finding was quieter and cost more. Sumeru Bank Limited runs a reconciliation of 430 items every working day, and that reconciliation is between the bank and its own core banking ledger. There is one party to it. The 430 is the daily list rather than one item for every loan decided, and it happens to sit at 430 because of how the bank's own volumes fall. A shared record has nothing to share when there is one party. Cutting settlement between five institutions to under a minute could do nothing whatever for the daily list, and the daily list is where the clerical time was actually going. The pilot worked and was not extended, and the honest reason is not that the structure failed. The reason is that a shared record solves a coordination problem this bank did not have.

How a lender, an analyst or a household actually uses this

An operations head at a lender reads any proposal of this shape with four questions and about ten minutes. Who holds the record today, by name? Who else would hold it, by name, and have any of them agreed in writing? How much time do those parties currently spend agreeing their versions with each other, measured rather than estimated? And what happens when an entry turns out to be wrong. On this structure that means naming who writes the offset and who explains the pair of entries to a customer.

An analyst reading a firm's announcement about a shared record does the same arithmetic from outside. Count the named parties in the announcement. If the number is one, the announcement describes a database and the interesting question is why the firm chose to describe it this way. If the number is five, ask what those five were doing before. The saving is the pairs and nothing else. The value of the arrangement is the reconciliation work it removes, so it can be estimated from the party count before anyone has chosen a single piece of software.

And a household meets the same test at a much smaller scale. Four flatmates who each keep their own note of who paid the electricity bill have six pairs to sort out at the end of the month, and one shared sheet on the wall removes all six. One person living alone, keeping one note, has nothing to remove, and the shared sheet would be an extra thing to maintain. Sumeru Bank Limited spent Rs 2,40,00,000/- building its intake chain and Rs 65,00,000/- a year running it, and neither figure covers the pilot. The flatmate example shows for nothing the test those figures should have been put against first.

Who sets expectations on a deployer here

The bodies that set the expectations, and where each one states them

Where a regulated lender in India shares customer records with named institutions under an agreement, the expectations on outsourcing, on where data sits and on what a customer consented to are set by the Reserve Bank of India at rbi.org.in. Where the institution 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 international work on shared records between institutions originates with the Bank for International Settlements at bis.org, and what India actually does is stated by the two Indian bodies named above rather than by that work.

Covered separately. The categories of digital asset a lender may meet, who controls one, and what happens when a private key is lost are covered separately. Publicly issued digital tokens traded on open markets are covered separately as well, and any Indian position on them is stated by the Reserve Bank of India and the Securities and Exchange Board of India. How a daily reconciliation is run is established elsewhere.

Five institutions settled between themselves without waiting. See what the pilot actually carried.

Sources

SourceDocumentSite
Reserve Bank of IndiaExpectations on a regulated lender covering outsourcing, data and what a customer consented to, and the Indian position on publicly issued digital tokensrbi.org.in
Securities and Exchange Board of IndiaEquivalent expectations where the institution is a market intermediary, and the Indian position on publicly issued digital tokens traded on open marketssebi.gov.in
Bank for International SettlementsMaterial on shared records held between institutions, cited as the origin of the international work rather than as the Indian positionbis.org

Sumeru Bank Limited, its intake chain and its pilot 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.