Customer Account Requests Done Right: Closures, Data Changes and Access Requests With a Record

Most account requests look like admin. A customer wants to close their account, update a phone number, remove an old device or get a copy of their statements. Each one takes a few minutes, and most are exactly what they appear to be. A small number are not: a contact detail change made by someone who has taken over the account, a closure that conveniently arrives while a transfer is under review, a request for data from someone who is not the customer. The difference between a routine request and an incident is usually whether anyone checked, and whether there is a record that they did.

This guide is for compliance leads and support leads who own how account requests are handled. It sets out the risk in each common request type, how to verify identity before changing anything, how to close an account that still has money or transfers attached, and what evidence an auditor will ask to see.

RemitSo is one platform that supports this work: it keeps account requests in one place with their origin and expiry, lets customers request closure in the app for your team to review, and records sign-ins, devices and KYC decisions. Your team still makes the decision on each request and owns the policy behind it.

Start by listing the requests you actually receive and deciding, once, how each is handled. Without that, support agents make the call case by case, and the same request is treated differently on different days. The table below is a starting point; adjust the approvers to your own structure and your licence conditions.

Two principles sit underneath the table. The person who handles the customer should not be the only person who can approve a high-risk change. And every request, approved or declined, should leave a record of what was asked, how identity was checked and who decided.

Email and phone changes deserve more care than any other routine request, because they control how you reach the customer and how the customer proves who they are. Once an attacker controls the contact details, they receive the one-time codes, the password reset links and the notices that would otherwise have warned the real customer. A contact detail change is often the first step in a takeover, not the last.

Confirm through the channel you already trust

The confirmation for a change should go to the existing email or phone, not the new one. Sending a code to the new number proves only that the requester holds the new number. If the customer has genuinely lost access to the old channel, treat it as a higher-risk case: ask for identity evidence and route it to a second person.

Read the sign-in history before you approve

A change request is easier to judge with the account's recent sign-ins in front of you. Look for:

• a new device appearing shortly before the request;
• sign-ins from a city or country the customer has never used;
• sessions where multi-factor authentication was not completed;
• a change request followed quickly by a new recipient or a larger transfer than usual.

Any one of these can be innocent: people travel and replace phones. Two or more together, close to a contact detail change, should stop the change until someone has spoken to the customer through a channel that pre-dates the request.

Tell the old channel after the change

Once a change is made, notify the previous email or phone. If the customer did not ask for it, that notice is often how you find out. Keep the notice short, factual and free of links that could be mistaken for phishing.

Closing an empty account is simple. The difficulty comes when something is still attached to it. Work through the account in a fixed order before approving.

1. Transfers in flight. A transfer that is paid but not yet delivered must finish or be returned before the account closes. Closing first leaves your operations team handling a payout for a customer who no longer exists in the app.
2. Deposits not yet matched. A payment the customer has sent that has not been matched to a transfer still has to be resolved: matched, or returned.
3. Recent card payments. If the customer paid by card, a chargeback can still arrive after closure. Note the open window on the closure record so that finance knows what to expect.
4. Wallet balance. Where your licence allows wallets, any stored value must be returned before closure. Who can do that should be tightly controlled, because returning stored value moves money out of your accounts.
5. Open compliance cases. A closure request during a review is not a reason to rush. Compliance decides whether the account can close now, and on what terms.

Closure reasons are data

Record a reason for every closure from a fixed list rather than free text: customer no longer needs the service, moved to another provider, unhappy with pricing, unhappy with service, closed by the business following review, and so on. A fixed list makes closure reasons countable. Free text does not. Over a quarter, a rising share of "unhappy with pricing" tells the pricing team something an individual ticket never would.

Be careful what you say

When an account is closed by the business, or a customer's closure request coincides with an internal report, the wording to the customer matters. Staff must not reveal that a report has been made or is being considered. Keep standard closure wording, agreed with compliance, and make sure support does not improvise it.

An auditor reviewing account requests usually picks a sample and asks you to walk through each one. For every request in the sample, you should be able to show:

• The request: what was asked, when, and through which channel.
• Where it came from: the device and IP address it originated from, and whether that matches the customer's usual pattern.
• The verification: what identity check was done, and its outcome.
• The decision: approved or declined, by whom, with the reason.
• The outcome: what changed on the account, and when.
• Expiry: requests that were never completed should expire rather than sit open indefinitely, and the expiry should be visible.

Run this test yourself before an auditor does. Pick ten recent requests at random, including at least two closures and two contact detail changes, and trace each from request to outcome using only the records in your system. Anything you had to reconstruct from someone's memory or a chat message is a gap.

The details below are illustrative, chosen to show the reasoning rather than to describe any real customer or operator.

A customer has sent money monthly for two years, always signing in from the same phone in the same city. On Monday morning, support receives a request to change the account's mobile number. The requester says the old phone was lost.

Step 1: read the context

The agent opens the customer's sign-in history. Overnight there is a sign-in from a new device, from a different country, where multi-factor authentication was not completed. The request itself originated from that new device and IP address. The old phone is still on the customer's device list.

Step 2: hold the change and use the trusted channel

The agent does not make the change. Following the written process, they contact the customer through the email address on file, which pre-dates the request. The real customer replies within the hour: they still have their phone, have not travelled, and did not ask for anything.

Step 3: secure the account

The unknown device is removed from the account, which ends its sessions. The customer resets their PIN and confirms their recipients are unchanged. The agent records the declined request, the reason and the evidence, and refers the case to compliance so the attempt can be assessed against the operator's policies.

Step 4: the closure request

Two days later, shaken by the attempt, the customer asks to close the account. The agent works through the closure order. There are no transfers in flight. A wallet balance remains, so the closure waits while a team member with wallet permissions returns the stored value. A card payment from the previous week is noted with its chargeback window. Compliance confirms nothing open blocks closure. The account is closed with the reason "customer request following security concern", the customer receives standard closure wording, and the full record stays on file.

Step 5: what the team learns

At the month-end review, the support lead counts closure reasons. Three closures that month cite security concerns, all after takeover attempts that were stopped. The team adds a short reassurance message to the closure flow for that reason and reviews whether multi-factor prompts should be stricter for sign-ins from new countries.

RemitSo gives compliance and support teams the records and controls described above. It does not decide requests for you: your team verifies identity, approves or declines, and owns the policy.

• Centralised user account requests (February 2026 release): account modification and access requests across the platform in one list, with request type, originating device and IP, expiry status and request details, so a sample can be audited from one place. See the admin features.
• Close account in the app: customers make a simple closure request in the app, and the request is reviewed by your team, so nothing closes without a person checking open transfers, balances and cases. See the customer app features.
• Configurable closure reasons: closure reasons are kept as a glossary you define, so reasons are consistent and countable.
• Device list: every signed-in device on one list; removing a lost phone stops its sessions, PIN and Face ID sign-in, so a compromised device can be cut off straight away.
• Login sessions: every staff and customer sign-in logged with time, IP address, city, country, client app, operating system and whether MFA was completed, with a filter for sessions where MFA was not completed, so agents can read the context before approving a change.
• KYC document decisions: customer documents are reviewed, approved or rejected, with rejection labels, so a name change backed by a new document leaves a decision on record.
• Wallet service permissions: where your licence allows wallets (an optional add-on), viewing a customer's wallet and returning stored value sit within the wallet service and are granted by role, from 89 separate permissions, so only the right people can move a balance out at closure.
• Accounting that is never edited: refunds are recorded with a reason, and mistakes are reversed rather than overwritten, so the money side of a closure is as traceable as the decision.

To see what shipped and when, read the release notes, or book a demo.