1. The Hook: A Stranger's Life, Delivered to Me
Parts 1and 22 were about price and process. This one is about custody: what happens to personal data when a lender treats an email address as proof of who someone is.
Here is a partial inventory of what reached my inbox, none of it addressed to me in any meaningful sense:
- A loan disbursal email, 14 minutes after the e-sign request, carrying the signed sanction letter and key fact statement for another person. Those pages contain that person's phone number and residential address. I have not reproduced either.
- A reservation cancellation from a holiday resort, for a booking I never made.
- A motor insurance policy for a motorcycle, with the vehicle details, addressed to someone sharing my name.
- A message from a credit information company about activity linked to my email, followed by a request for my passport, Voter ID and driving licence if I wished to dispute it.
- A collection notice sent on 22 September to a list in which, by my count of the header, about 65 other email addresses were openly visible alongside mine.
The pattern is one wrong address, many systems, and nobody checking. I am a bystander here. The borrower is someone I have never met and I hold no view about them. My interest is in the plumbing.
2. Pulling Back the Curtain: The Personal Logic
2.1 The email address as a routing key
In a modern lending stack, an email address does three jobs at once. It is a delivery channel (statements, notices). It is a login or recovery handle. And it is a join key that lets separate systems recognise that two records belong to the same human. When the address is wrong, every one of those jobs fails in the same direction: the wrong person receives the data, and the wrong person is attached to the record.
What I saw is consistent with that chain reaction. A single address entered on a loan application surfaced in a resort's booking system, an insurance broker's mailing flow and a credit-information service's alerts. I do not know how each came to hold the address and will not guess. The point is that an unverified address does not stay in one database.
2.2 A notification is not a verification
The e-sign request for the loan agreement reached my mailbox at 5:32 PM on 4 September. The signature certificate on the agreement is also stamped 5:32 PM. I cannot determine from the documents how the signer reached the signing page. But a signature that lands in the same minute as the email is consistent with the email being a notification, not a gate. In other words, nothing in the timeline requires the mailbox owner to have clicked, entered a code, or even opened the message.
That distinction matters. Proving that someone can receive mail at an address is a different control from proving they own it. Only the first was needed for the system to function. In my notice to the company I stated that I never received a one-time code or any confirmation request for the address. I can describe my side of the wire. I cannot see theirs.
2.3 The blast radius of a broadcast
The 22 September collection notice used the visible recipient field of the email, with roughly 65 addresses listed. Each of those recipients could see the email addresses of every other recipient, and each was addressed in the message as a person in default. The sender used a corporate mailbox. The fields that would have hidden recipients from one another exist in every mail client.
Think about what that exposure amounts to for the people on the list. A private contact detail is tied, in the eyes of every other recipient, to an allegation of non-payment. If even a handful of those addresses were wrong, as mine was, then the exposure falls on people who owe nothing.
I am not offering a legal conclusion. India's data-protection and IT frameworks, along with the RBI's digital lending directions, are the documents I would read to understand what a lender is expected to do with borrower data. I am not a lawyer, and I would treat any reading of them as a question for a qualified professional.
2.4 Knowing and continuing
What separates an accident from a process failure is what happens after the first correction. Mine was dated 13 July, when I wrote that I had applied for nothing. The company's later written replies acknowledged that the loan is registered under my email ID, expressed an apology, and asked me for identity documents so the investigation could proceed. Meanwhile, automated messages kept arriving at the same address, with threats of field visits and reference contacts.
Two systems existed side by side. One was a grievance desk that said sorry. The other was a collections engine that did not hear it. Neither seems to have had the authority, or the plumbing, to stop the other. I call this an ownership gap. Everyone I wrote to treated the problem as someone else's department.
The same pattern appeared in the credit-information exchange. In my letter to that company I recorded that, instead of explaining how my address came to be on a record, they asked me for more of my personal data. When the response to a data-misattribution complaint is a request for more data, the cost of fixing the error is transferred to the person least responsible for it.
3. The Scalable System: The Modern Framework
I condensed the lessons into three tools that anyone analysing a data-heavy financial business can use. I apply them to companies. I do not present them as instructions for individuals.
Tool 1: The Data Blast Radius Score
For any single data leak or misdirected message, I count outward from the event.
- Recipients of the data. How many parties received it who should not have?
- Fields exposed. Which of the following were visible: name, email, phone, address, loan status, identity numbers?
- Attached allegation. Did the exposure carry a negative claim about the person (default, fraud, non-payment)?
- Duration. How long did the wrong association remain after the first written notice?
A message exposing one field to one stranger is a small radius. A message exposing identifiers plus an allegation to dozens of strangers, and repeated over weeks, is a large one. I find that scoring the radius forces the discussion away from adjectives and towards facts.
Tool 2: The Verify-Before-Attach Checklist
This is the control I look for in any onboarding flow when assessing a lender's quality.
| Check | What I look for |
|---|---|
| Ownership proof | A one-time code or confirmation link that the mailbox owner must act on, not just receive |
| Bounce and objection handling | A rule that a reply of the form "this is not my account" suspends outbound messages automatically |
| Quarantine | A flag that stops all automated recovery messages the moment a data-ownership dispute opens |
| Correction path | A way to remove an address without demanding fresh identity documents from the person who is not the customer |
A lender that has all four is paying for the cost of accuracy before it lends. One that has none is shifting that cost to the public.
Tool 3: The Notice-to-Action Latency
This metric is deliberately plain. Take the date of the first written notice and the date the problem is actually fixed. In this case the first notice came within 36 minutes of the e-sign, and the last email in my file is from mid-October, with no removal confirmation. I record it as notice-to-action latency: more than six weeks, still open. In well-run companies I would expect that number to be measured in hours or days. I treat it as a leading indicator of how a firm will behave when something larger goes wrong.
4. The Smart Investor Summary
- Receiving is not owning. Systems that test whether an address can receive mail, without testing who controls it, create a pool of misattributed data.
- Cheap onboarding has an external cost. When the cost of an error lands on uninvolved people, the firm that profits from speed does not price it. Observers can price it by scoring blast radius and latency.
- Broadcast mistakes are a controls signal. A visible recipient list is a small error with large consequences. It tells me about training, tooling and supervision all at once.
- Apologies without plumbing do not close the loop. A grievance desk that agrees and a collections engine that carries on show two disconnected systems.
- Asking the wrong person for more data is a design flaw. Any remediation path that begins with new sensitive documents from a non-customer deserves scrutiny.
This was one person's experience with one lender and the systems around it. The companies mentioned are welcome to respond and I would publish their reply in full. Future posts in this series will return to the frameworks above with other case studies.
0
Post a Comment