Rescuing Stalled Onboarding: Unfinished ID Checks, Provider Resets and When to Withdraw an Approval

Most onboarding problems in a money transfer business are not dramatic. Nobody is trying to launder anything. A customer opened the app, started the identity check on a bus, lost signal and never came back. A document was approved, then the verification provider reset the record. A sending country was switched on without the fields the regulator expects. Each of these leaves a customer stuck, or worse, verified on the wrong basis, and each one is invisible unless someone goes looking.

This guide is for compliance heads and onboarding leads who own the queue of customers who started but never finished, and who decide whether an approval on file should stand.

RemitSo is one way to run this: customers can resume an unfinished ID check, alerts flag provider resets, and admins can withdraw an approval to clear a stalled case. A person still decides whether an approval stands, and your policy still sets what counts as verified. The method below works on any platform.

Where the ID check sits inside the first transfer rather than at sign-up, the customer has already chosen a recipient and seen a rate when asked for a document and a selfie. They have a reason to finish, and a stall costs you a transfer that was moments from happening. Stalls fall into five groups.

1. The customer walked away mid-check

Poor lighting, a document not to hand, an interruption. If the platform makes them start again from nothing, many will not bother.

2. The check finished but needs a person

A face match below threshold, an unreadable document, a mismatch between profile and document. The customer is waiting on you.

3. The document was rejected and the customer does not know why

A rejection with no usable reason produces silence or the same photo again. A specific label ("document expired", "image blurred") tells the customer what to fix.

4. The provider changed the record underneath you

Providers sometimes reset a check or switch a record off on their side, through their own controls, a clean-up or a manual action. Your platform may still show the document as approved. That is the most dangerous stall, because it does not look like one.

5. The country was never set up properly

If the sending country does not ask for a first name, or offers no proof of identity customers there can complete, they either cannot verify or end up verified with no name on file. No amount of chasing customers fixes a configuration fault.

Sort stalled customers by cause, not by age. A customer stuck for two hours by a provider reset matters more than one who never reopened the app.

One stalled customer is usually about that customer. Several from the same sending country in one week is usually configuration.

The cheapest recovery is the customer who has already done half the work.

• Let them resume, not restart. The app should take them back to the step they left, not the beginning.
• Remind them with context. "Finish verifying to send your transfer to [recipient]" works better than "Complete your profile", because the customer remembers why they started.
• Do not let reminders become pressure. One or two prompts are service; a daily stream is a reason to uninstall. Agree the reminder policy with compliance.

Keep abandoned checks separate from the review queue: they need a prompt, not a decision.

A rejection is a message to the customer as much as a compliance decision. Before an analyst rejects, they should be able to answer:

1. Is the reason specific? Use a label the customer can act on. "Not acceptable" invites the same document again.
2. Is the document type one this country actually offers? Rejecting a document because it is not on your list, when your list for that country is wrong, punishes the customer for your configuration.
3. Is this a reviewer override? If the provider passed the check and the analyst is rejecting anyway, or the reverse, the reason should be written down. A reviewer can override the automated result, and the reason should be kept with the decision.

Withdrawing an approval stops a customer who may have done nothing wrong; leaving it may mean relying on a check that no longer exists.

When a provider resets or switches off a KYC record, a well-built platform does not silently change the local status. It leaves the document as it was, including an approval, and raises an alert so a person decides whether it should stand. That is deliberate. An automatic downgrade would block legitimate customers every time a provider ran housekeeping; an automatic keep would let a withdrawn verification carry on unnoticed. The decision belongs to compliance.

Withdraw the approval when

• The provider tells you the original check was invalid, for example the document was later found to be fraudulent, or the face match was reversed.
• The record was switched off for a reason that goes to identity, not housekeeping.
• The customer was verified while the sending country was misconfigured, and the record is missing something your policy requires, such as a first name.
• You cannot establish why the provider changed the record and your policy says you must be able to evidence the basis of verification.

Leave the approval in place when

• The provider confirms the reset was administrative and the original result stands.
• You hold independent evidence that supports the approval, such as a reviewer decision made on the document itself with the reason recorded.
• The record is complete, the country was correctly configured at the time, and nothing about the change goes to the customer's identity.

Either way, record what you decided and why against the customer. "A person looked at it on this date and decided this, for this reason" is the answer an auditor wants.

Before you withdraw, check what depends on the approval. A transfer already in progress that relied on the document should go back to asking the customer for a replacement, not travel on to a payout partner that refuses it days later. The same applies when a document expires.

When deleting documents is the right fix

Sometimes the wrong thing is on file: a document against the wrong customer, or a duplicate that confuses review. Deleting identity documents clears the way for clean re-verification. Do it under a permission only the right people hold, and check record-keeping obligations first: delete only what verification did not rely on.

Much onboarding trouble is created the day a sending country goes live. Two settings matter most: which documents the country accepts, and which customer attributes it asks for. Check:

• Name fields. Does the sign-up and verification flow ask for a first name, and any other name parts your rules and reports rely on? A customer who verifies without a name on file is a record you will have to reopen.
• Accepted documents. Is there at least one proof of identity a typical customer in that country can complete? Passport-only works for some markets and shuts out most customers in others.
• Required attributes. Address, date of birth, nationality, occupation: whatever your policy and your regulator expect, set as required for that country, not assumed.
• AML tiers. As a customer's sending total grows, your AML rules will ask for further documents. Check those documents can actually be collected in that country, or customers will hit a wall at the second tier.

If a country goes live with gaps, you want an alert that does not go away. In RemitSo, "Sending country not set up for customers" repeats daily until fixed. Then review the customers who verified during the gap and decide, using the test above, whether their approvals stand.

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

An operator sends from two countries. On Monday morning the compliance lead opens the queue and finds 41 customers who started verification in the past week and have not sent a first transfer.

Step 1: sort by cause

• 24 started the ID check and did not finish.
• 7 are waiting for compliance review.
• 5 had a document rejected and have not re-submitted.
• 2 have a "KYC reset at the provider" alert against an approved document.
• 3 are from the newer sending country, and the "Sending country not set up for customers" alert has fired every day since Thursday.

Step 2: investigate before you queue

The lead starts with the last two groups. The country alert says no first name is being asked for. Configuration is corrected that morning. Of the 3 customers, 2 were verified without a first name on file. Their approvals are withdrawn with a note, and they are asked to complete their details and verify again. The third had not finished and simply resumes.

For the 2 provider resets, the lead asks the provider why. One was an administrative re-run; the original result stands, and the approval is left in place with the reason recorded. The other was reset after the provider flagged the document; that approval is withdrawn and the case passed to the analyst handling suspicious activity.

Step 3: clear the queues

Analysts work the 7 reviews. Onboarding looks at the 5 rejections: 4 have specific labels and get a reminder; 1 was rejected as "not acceptable", which the analyst re-labels as "document expired" before the customer is contacted. The 24 abandoned checks receive one reminder that names their pending transfer.

Step 4: measure the week

By Friday, 15 of the 24 have finished. Three of the week's 5 rejections were for one document type in the newer country; the lead raises it as a possible configuration issue.

Track a small number of measures every week, split by sending country:

• Started-to-verified rate: the share of customers who start an ID check and finish it.
• Resume rate: of those who abandoned, the share who came back and finished.
• Time in review: how long a case waits for a person once it is sent to review.
• Rejection rate by label and document type: a spike on one label is a signal.
• Provider changes acted on: resets and switch-offs, and how long each waited for a decision.
• Days with a configuration alert open: this should be zero for any live country.

Set targets from your own baseline; the trend and the country split matter more than any borrowed benchmark.

RemitSo gives compliance and onboarding teams the signals and controls described above. Your team still sets the policy and makes each decision.

• ID check inside the first transfer: customers verify when they have a reason to finish, with ID, selfie and a live face check. See the customer app features.
• Resume an unfinished ID check: customers pick up an identity verification they had already started, so an interruption does not mean starting again.
• Withdraw an approval, delete identity documents: admins can withdraw a KYC document approval and delete identity documents to resolve a stalled onboarding, so a stuck case can be cleared and re-verified cleanly.
• Withdrawals and expiry reach the money: when an approval is withdrawn, a document deleted or a document expires, transfers that relied on it go back to asking the customer for a replacement, and return to where they were once one is approved, instead of failing at the payout partner days later. Before you confirm, the screen says how many transfers will be sent back; transfers already with the partner or paid out are never pulled back.
• Provider change alerts: a hold or reset made in the identity provider's own dashboard reaches the console. "KYC reset at the provider" and "KYC record switched off at the provider" leave the document with its status, including an approval, and tell a person to decide whether it should stand.
• No duplicate documents: a verification result delivered twice does not create a second document, so the review queue shows each customer once. Liveness recordings and the provider's original verification record are kept as evidence.
• Disable or restore document types with a reason: a disabled document type stops being offered to customers, a deleted type can be restored, and both ask for a reason that is kept in the audit log, so a country's document list can change without losing why.
• Review and rejection alerts: "KYC requires compliance review" and "KYC rejected – action needed" go to the people subscribed to them; documents are approved or rejected with rejection labels, and a reviewer can override with the reason kept.
• Country document settings and customer attributes: set per sending country which documents are accepted and which details are required.
• "Sending country not set up for customers": repeats daily until a country asks for a first name and offers a proof of identity customers can complete.
• Scout and the Compliance Dashboard: documents required and compliance decisions waiting, measured every five minutes, each part granted by role. See the admin features.

See the release notes or book a demo.