Playbook, fintech app
The file outlasts the account, and that is a duty rather than a choice
The two things a customer most wants gone are the identity documents they handed over at the start and the list of everything they have paid for since. Those are precisely the two a regulated firm has least freedom to remove, because record keeping rules in most markets require both to be held for a set period after the relationship ends. That is an unusual sentence to have to say pleasantly, and it is the sentence this pair exists to get right.
Why this is not the general answer
The handling pattern for data deletion requests holds across every trade. What follows is the part that does not.
- Erasure is partial here as a matter of obligation rather than policy, so the honest answer describes a duty the firm is under rather than a decision it has taken, and softening that into a preference invites an argument the firm cannot win.
- The retention clock usually starts when the relationship ends rather than when somebody asks, which means two people sending an identical message get different answers depending on a date neither of them mentioned.
- Closing an account and erasing a file arrive in the same message and are different acts: one stops the product working, the other runs into a period that the closure itself started.
- Where the card is issued by another firm, part of the record sits with a company the customer has never contacted, so a complete answer names roles rather than implying one company holds everything.
How it arrives
- delete my account and all my personal data
- how long do you keep my id documents after i close my account
- can you erase my transaction history
- i closed my account last year why do you still have my details
- do you have to keep records even if i object
- who holds my information if my card is issued by another firm
What has to be indexed for this to work
| The retention schedule, split by record type | Identity documents, transaction records and correspondence are usually held for different periods and measured from different events. One number covering all of them will be wrong for two of the three, and the person reading it will notice at exactly the wrong moment. |
|---|---|
| The published statement of your record keeping obligation | The paragraph saying an obligation exists and that it survives closure, written for a customer rather than for a reviewer. It should say that an erasure request is honoured to the extent the obligation allows, without listing the internal criteria behind any check. |
| Closure and erasure, described as two separate acts | What closing does to the balance, the card and the arrangements pointed at the account, and what it does not do to the file. Customers use one word for both, and every avoidable complaint in this pair comes from that. |
| Who else holds a copy, described by role | The card issuer, and anyone else in the chain with their own duty to retain. Naming the role and the reason is more useful than a list of company names, because the customer is trying to work out who to write to next. |
The reply
Some of this can be removed on request and some of it cannot, and the reason is a record keeping duty rather than a policy we chose. Identity documents and transaction records are held for the periods in our retention statement, measured from the point the account closes rather than from the date of a request [1]. Closing an account and erasing the file behind it are separate things, and the first does not do the second [2]. I cannot see any account, confirm what is held about you, or remove anything. Leave your name, an email and what you are asking for, and it goes to the people who handle these.
It concedes the uncomfortable half in the first sentence, because a reply that opens with process reads as a firm avoiding the word no. Attributing the limit to a duty rather than to a decision is not a softener, it is the accurate description, and it moves the conversation away from persuasion. Naming the starting event matters because the length of the period is the next question every time.
Where it stops
The trigger. Any request to erase, remove or supply a copy of personal information, and any question about what is held on a named person or account.
This is a formal request rather than a question, and it has to reach the team who handle them under our published timescales. Leave your name, the email the account was opened with and what you are asking for, and it will be recorded rather than ending here.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never confirm that anything has been erased, closed or scheduled for removal, because nothing in this channel writes to any record.
- Never state a retention period that is not in your own published statement, and never give one period for every kind of record.
- Never confirm whether an account exists, has existed, or has been closed, for any name or email.
- Never explain which activity causes a record to be kept longer, since that describes controls that are deliberately not published.
Questions
- Can it delete anything at all, even a marketing preference?
- No. It reads documents and writes nowhere, so every request here leaves as a message to the address you nominate. That is worth being blunt about in this trade, because a customer who believes a chat window actioned an erasure will be furious twice: once when nothing happened, and again when they learn about the retention period.
- Is publishing our retention periods risky?
- Publishing them is the safer side. The periods come from obligations you did not invent, and a customer who reads them before asking is far calmer than one who is told a number in the middle of a dispute about being misled. What should stay unpublished is the reasoning behind any individual case.
- People ask us to delete a payment they are embarrassed about. What should it say?
- That the transaction record is part of what has to be kept, in the same neutral wording used for everything else, with no comment on the payment itself. The assistant has no view of it anyway, and the value of the answer is that it treats the request as ordinary rather than as something to be discussed.
Keep reading
- Everything for a fintech appFees, limits and identity checks are safe ground. Balances, transactions and anything reading as a personal recommendation are not.
- Handling data deletion requests in generalA deletion request is a request with a clock on it, not a question. The characteristic failure is silence, so it always has to reach a person.
- A procurement reviewer and a frightened individual, typing the same wordA corporate assessment and a nervous customer arrive in the same box. Neither is served by being answered as the other one.
- A barrier at verification is not an inconvenience, it is a closed accountA photo capture, a liveness step and no published alternative. On a money app an access barrier stops the account working at all.
- The document exists, and the charge on it cannot be discussed hereStatements, fee breakdowns and tax paperwork on a money app. What the schedule explains, and why no charge on an account can be read.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.