Data Sharing in Finance: The Rails and the Permissions
Finance data moves between institutions on four arrangements, and they are not four grades of one thing. One hands over a sign-in. One hands over a downloaded copy. One is a contract between two institutions the customer is not part of at the moment of transfer. One is an instruction the customer gives, and that instruction is itself the proof of what was permitted.
Two separate things have to make that journey, and almost every confusion in this subject comes from treating them as one. There is the route the data takes, and there is the statement that it may take it. Different people build them, different tests cover them, and when they break they break separately. A rail moves data and a permission decides whether it may move. The combination that hurts a firm most is a rail working perfectly under a permission that is wrong, and it hurts because nothing ever stops.
What is actually moving when finance data is shared?
The whole subject fits inside a rented flat, so start there. A landlord wants proof that the salary a prospective tenant described actually arrives every month. There are only a handful of ways that proof can reach him. The tenant could hand over the banking sign-in and let him look for himself. The tenant could download three months of statements and send him the file. The tenant's bank could pass it to him under an arrangement the two of them already have. Or the tenant could tell the bank, in a way that is written down, to send those three months of salary credits to that landlord, for that reason, for that long.
Every one of those has an exact equivalent in finance, and only the last of them leaves behind a record of what was agreed to. Data sharingMoving a customer's records from the institution holding them to another institution, on some arrangement. in a bank is not one activity. Sharing is a choice between four arrangements that differ in what they ask of the customer, what the recipient can rely on afterwards, and what anybody can prove a year later.
The arrangements differ mainly in who is standing where, so the three parties are worth naming plainly. There is the holder of recordThe institution the data already sits with, which produced it and can vouch for it., being the institution the data already sits with. There is the customer, whose data it is. There is the recipient, being the institution that wants it for some decision. The data and the permission travel between those three parties on separate paths, and an arrangement is best described by which path each one takes.
Is the rail the same thing as the permission?
No, and the difference is worth a section of its own because it is the one that decides how a failure will announce itself. A rail is the route. The route is plumbing: connections, formats, timings, retries. A permission is a statement about what may travel on that plumbing, made by somebody with the standing to make it. A firm can build an excellent rail and attach a permission that says nothing checkable, and the rail will carry the data faithfully anyway.
Think about a courier business. If the van breaks down, nothing arrives and the phone starts ringing, and the whole town knows by that evening. If the van runs perfectly and the address slips are being printed wrong, parcels keep arriving at the wrong doors every single day, and the only person who ever finds out is whoever eventually opens one that is not theirs. A broken rail announces itself because everything stops, and a broken permission stays silent because everything keeps moving.
Sumeru Bank Limited, an invented bank, built its front door so that one of those failures would be loud on purpose. Its consent step is a gate rather than a formality, and in one month 112 files were stopped there and sent to a person because the consent record was incomplete. The bank was choosing to have its permission fault behave like a rail fault: something stops, somebody sees it, a queue builds. The nine fields that record has to hold, and what those 112 files were missing, are set out under consent management.
What are the four arrangements the data can move on?
Four, and they are worth numbering. The numbers are how the four are referred to from here on, and the numbering is not a ranking of modernity. Read them by what each one leaves behind, and the resulting order reverses the one people usually put them in.
Arrangement 1: the customer hands over a credentialA customer's own means of signing in, which cannot be shared without handing over everything behind it. and the recipient signs in as them. Arrangement 2: the customer downloads a file and uploads it, so the recipient receives a picture of a record rather than a record. Arrangement 3: a direct arrangementA transfer between two institutions under contract, with the customer not in the loop at that moment. between two institutions under contract, with the customer not in the loop at the moment of transfer. Arrangement 4: a consent driven railA route where the customer instructs a holder to send named items to a named recipient, and the instruction is a record., where the customer instructs the holder to send named items to a named recipient for a named purpose and period, and the instruction is itself a record.
Which of the four arrangements is refused before anything is built, and what is the reason?
Why is handing over a credential refused before anything is built?
Because it is not a document being passed across a table. A credential is a door being held open, and the difference matters at the level of what can be built on top of it. Every other arrangement here can be narrowed: fewer items, sent once, sent to a single recipient. A credential has no narrow version. The moment it changes hands, the recipient can reach every screen, every balance, every stored instruction and every other product the customer holds at that institution, for as long as the sign-in keeps working.
Then there is the part that is easy to miss. Nobody can say afterwards what was taken. A signed-in session leaves the same trace as the customer's own session, so the institution's records show the customer looking at their own accounts. There is no list, no moment, no boundary and nothing to compare a later complaint against. An arrangement that cannot be narrowed and cannot be recorded is not a weak control, it is the absence of one, and that is why it is refused at design rather than managed afterwards. Sumeru refused it before a line of the front door was built, and that refusal is why the month set out below has three arrangements in its mix and not four.
What is the difference between a record and a picture of a record?
Arrangement 2 is the one almost every firm still runs, and it survives because it works often enough to feel reasonable. The customer opens their banking app, downloads a statement, finds the file again and uploads it. The content that arrives can be entirely accurate. Accurate content is exactly why the failure is hard to see: nothing about the numbers is wrong.
The file is missing its origin, not its content. A record produced by the holder carries something that ties it to the holder. A downloaded fileA copy of a record, which carries the content and no evidence of where it came from. carries the content and leaves that tie behind. So the recipient can read every figure and still cannot establish two things: that the file came from the institution it appears to have come from, and that nothing in it was altered between the download and the upload. A picture of a record is information the recipient cannot rely on, and the fact that it is usually true does not make it evidence.
There is a second cost, and it falls on the customer rather than on the recipient. Arrangement 2 asks a person to do the following, in order, on a handset: open one app, find the right statement, choose a period, save a file, leave that app, open another, find the file again in whatever folder it landed in, and upload it, on whatever connection is available. Every step in that list is a step a person can fail to complete.
A recipient receives a downloaded statement from the customer. Which of these can it not establish?
Where does the customer sit in a direct arrangement?
Outside the transfer, at the moment it happens. Arrangement 3 is ordinary, legitimate and often the best available answer, so the customer's absence needs saying without a raised eyebrow. Two institutions have a contract. Under it, one sends the other agreed items about a shared customer. Nobody sends the customer a message that afternoon. Nobody asks them to do anything.
Two consequences follow, and they point in opposite directions. The first is that this arrangement asks the customer for nothing at all, so it loses nobody. In the month set out below, 886 applicants were on a direct arrangement at the document step and not one of them stopped there. Zero, out of 886. The second consequence is the price of the first. The evidence that the customer permitted it lives in a contract between two institutions and in whatever they agreed when the relationship was opened. The customer cannot read that contract, and it is not attached to this particular transfer on this particular day. The question to ask of a direct arrangement is never whether it is proper, but where the record of permission is kept and whether it names anything specific enough to check.
Two institutions transfer a customer's data under a contract between them. What is the customer's position?
What does a customer instruction have to name to work as a permission?
Four things, and dropping any one of them turns the instruction into something weaker while leaving it looking exactly the same. Arrangement 4 is where the customer tells the holder to send something to the recipient, and the useful property is that the instruction is not a separate consent form sitting beside the transfer. The instruction is the transfer's own paperwork.
The four are the named itemsOne field each, listed rather than described, which is what makes a permission checkable afterwards., the named recipient, the named purpose and the named periodHow long the permission runs, without which a one-off instruction quietly becomes a standing one.. Taken one at a time, each shows what its absence permits. Without the items, the instruction covers whatever the holder decides to send, a scope broader than anyone intended and impossible to test. Without the recipient, the permission runs to somebody unnamed. Without the purpose there is no inside, so no later reviewer can say whether a use was inside the permission or outside it. Without the period, a one-off becomes standing, quietly, for years.
What are the four things a customer instruction has to name for it to work as a permission?
How does that instruction line up with a consent record?
Closely, and not completely, and the gap is where firms get caught. The nine numbered fields a consent record has to hold are settled under consent management, so take them as given. Lay the instruction against them and four of the nine are answered by the instruction itself: the items are field 3, the recipient is field 2, the purpose is field 4 and the period is field 5. A fifth, field 1, being who is giving consent identifiably, comes free from where the instruction is given. The customer gives it at the holder, having already been recognised there.
Four fields are left that no instruction carries on its own: the date and time it was given, how it can be withdrawn and by which route, what wording the customer was shown, and what was actually on the screen at the moment they agreed. The trap is that a rail feels complete, so the four fields it does not carry are precisely the ones nobody builds.
Sumeru met that trap in a specific and instructive way. Its consent record was missing three of the nine at go-live, and one of the three was field 5, the period. Now notice where the period actually existed: every instruction on the rail names one, and those instructions sit at the holder of record, an institution other than the bank. So the bank could truthfully say the period had been stated and could not produce it from its own records. Evidence that exists at the other end of a rail is not evidence the firm holds, and a firm that relies on the rail's paperwork without copying it into its own record has an evidence problem with no symptom. The silent quadrant set out above arrives in a real month.
A rail instruction names the items, the recipient, the purpose and the period. Which parts of a consent record does that still leave to be recorded?
What does each arrangement leave behind, set side by side?
Put the four in one table and read the last column first. The last column decides what a firm can say when somebody asks, two years later, why it held a particular customer's salary history.
| Arrangement | What the recipient gets | Where the proof of permission sits | Checkable later? |
|---|---|---|---|
| 1. Handed over credential | Reach into everything | Nowhere | No |
| 2. Downloaded file | A copy, origin removed | Nowhere specific to this transfer | No |
| 3. Direct arrangement | Agreed items | A contract between two institutions | Partly |
| 4. Consent driven rail | Named items only | The instruction itself | Yes |
The ordering that falls out of the last column is not the ordering most firms use when they choose. Most choose on what is quickest to build against the recipient's own systems. Speed of building puts arrangement 2 first because arrangement 2 needs nothing from anybody. Choosing an arrangement by what it costs to build is choosing what evidence will exist afterwards, without noticing that the choice is being made.
What did one month's mix actually look like?
Sumeru Bank Limited ran its retail loan front door on three of the four arrangements in month 6, its steady state. Arrangement 1 was refused before the front door was built, so it contributed nothing at all. Of the 8,600 files that completed the path that month: 5,246 came in on the consent driven rail, being 61.0 per cent; 2,494 came in on the downloaded file route, being 29.0 per cent; and 860 came in on a direct arrangement, being 10.0 per cent. The three routes add to 8,600 and the shares add to 100.0. The mix describes one bank's deployment rather than an industry pattern.
Before the next number arrives, one reconciliation has to be stated. The population is about to change, and merging the two populations would be the easiest mistake to make. The mix above is counted on files that finished the path. The route counts below are counted on applicants who reached the document step. Some of those applicants stopped before the end, making that set the larger of the two. The 9,380 at the step and the 8,600 that completed are two different populations and no share may be read against the wrong one. On the rail, 5,498 applicants reached the document step and 5,246 files finished, and the losses in between are worked out under electronic KYC and digital onboarding, from the recorded route counts rather than from a separate measurement.
Which route were the people who stopped at document upload on?
Here is the month's most useful finding, and it was sitting in the bank's own data the whole time. At the document step, 9,380 applicants arrived and 480 did not finish. AbandonmentA customer who starts a step and does not finish it, which is only actionable once it is split by route. of 480 is what the monthly pack said, and it is a true number.
Now split those 9,380 by the arrangement they were actually on. 5,498 were on the rail, and 48 of them stopped, being 0.87 per cent. 2,996 were on the downloaded file route, and 432 of them stopped, being 14.4 per cent. 886 were on a direct arrangement, and none stopped. The entrants add to 9,380 and the two losses add to 480. The route carrying 31.9 per cent of the people at that step produced 90.0 per cent of the loss there, at a rate about sixteen times the rail's, and that ratio is the whole comparison in one number.
Keep the two bases separate even inside this finding. The downloaded file route is 31.9 per cent of the applicants at the step and 29.0 per cent of the files that completed, and neither share describes the group that the other one counts. Putting one of them against the other population is exactly the error the reconciliation above exists to prevent.
What is the abandonment rate on each of the two routes that lost anybody, and what does the ratio show?
Reading 0.87 and 14.4 as two smallish percentages is easy, so say the ratio out loud before moving on. One route stopped roughly 9 people in every 1,000 who used it. The other stopped roughly 144 in every 1,000. The rail was about sixteen times kinder than the upload route to the same customers on the same step in the same month. And this is a design result rather than a finding about people. The applicants on the upload route wanted the loan exactly as much as the ones on the rail. The upload route asked them to do more, on a handset, with whatever connection and whatever storage they had.
Before the control below is moved: 480 applicants stopped at the document step, and the upload route carried 2,996 of the 9,380 people there. How many of the 480 were on it?
Move people between the two routes and watch the reported total move
886 applicants sit on a direct arrangement that lost nobody, so 8,494 of the 9,380 at the step are the ones being routed. The two rates are held at the month's measured values, 48 in 5,498 on the rail and 432 in 2,996 on the upload route. Moving people between routes is assumed not to change either rate, and the assumption is not a finding.
applicants placed on the upload route: 2,996 of 8,494
Educational illustration. Figures are the invented bank's own and describe one deployment. The default setting is the month as it ran: 2,996 applicants on the upload route and 5,498 on the rail, giving 480 who stopped, of which 432 came from one route. The rates are 0.87 per cent on the rail and 14.4 per cent on the upload route, held fixed because this bank measured them once. With nobody on the upload route the step would lose about 74 people; with everybody on it, about 1,225.
Why did one reported number hide all of that?
Because a total contains no statement about what anybody was being asked to do. The monthly pack was organised by step, and on paper the document step was one step, the same one, for all 9,380 people. It was not. The step was two quite different requests wearing one label, and the label is what got measured.
The failure: 480 was true, and unactionable
The figure was correct every month. Nobody had made an error in producing it. The figure merged three populations that were asked three different things, and the merge happened before the number was written down, so it could not point anywhere. The split needed no new system, no new collection and no new field. The split sat in the same data throughout, and nobody had taken it. A number that cannot be wrong and cannot be acted on eats the attention a usable number would have earned, and that makes it the most expensive kind of reporting a firm can run.
A step in a firm's own process reports 480 abandonments a month. What is the first thing to ask for?
How this is used in a live operation
An operations lead stops reporting abandonment by step and starts reporting it by route within a step, usually a change to one query rather than a project. A credit or product manager reads a completion rate only with the route mix printed underneath it. A completion rate that improves while the route mix shifts is reporting routing rather than the product. A reviewer in a control function asks one question of every sharing arrangement: where does the proof of permission sit, and can this firm produce it without asking another institution? An analyst reading somebody else's disclosed numbers treats a single funnel figure the same way as any other average: as a fact about a mixture rather than about anybody in it.
One more thing about that month is worth stating plainly. The failure in it is a measurement failure rather than an arithmetic one. The bank's own papers carry the cost of the chain in money: Rs 2,40,00,000/- to build it once and Rs 65,00,000/- a year to run it. No rupee figure for the 432 people who could not finish an upload was ever produced, so they appear in none of those papers as money. The costs of a system get converted into money and the costs of a routing choice get left as a count of people, and that is precisely why one of them gets managed and the other does not.
Where the rules for this actually live
Three bodies, and what each one covers
Expectations on a regulated lender that shares or receives customer data sit with the Reserve Bank of India at rbi.org.in, and where the institution is a market intermediary the Securities and Exchange Board of India at sebi.gov.in states its own. Payment rails in India sit with the National Payments Corporation of India at npci.org.in. Consent obligations are set by those three bodies rather than by industry practice, and each states them for the institutions it supervises.
Consent management sets out what a consent record has to hold, field by field, and what servicing a withdrawal costs the desk. The whole onboarding path, where else applicants are lost along it and how the step completion rates behave together, is set out under electronic KYC and digital onboarding.
Sources
| Source | Document | Site |
|---|---|---|
| Reserve Bank of India | Expectations on a regulated lender covering customer data, outsourcing and digital lending | rbi.org.in |
| Securities and Exchange Board of India | Equivalent expectations where the institution receiving the data is a market intermediary | sebi.gov.in |
| National Payments Corporation of India | Material on the payment rails customer instructions travel over in India | npci.org.in |
| Cathy O'Neil | Weapons of Math Destruction, on how a system's errors concentrate on an identifiable group rather than scattering across a population | Crown, 2016 |
Sumeru Bank Limited is invented.
Educational material. Not advice on any investment, tax, budget or market position.
