When a Compliance Decision Changes, the Money Follows: Withdrawn Approvals, Expired Documents and Provider Holds

Identity checks are usually designed for the first day: the customer signs up, uploads a document, passes a face match, and is approved. The harder question comes later. What happens to the transfers already in progress when an approval is withdrawn, a document expires, or the identity provider puts the customer on hold in its own dashboard? On many platforms, nothing happens at all until a payout partner refuses the transfer days later, and by then the customer has paid and is waiting.

This guide is for compliance heads, MLROs and operations leads who want KYC decisions to reach the money as soon as they are made. Where RemitSo handles a step, we say so.

A KYC decision is not a one-off event. It is something every later transfer leans on. Three things commonly change after approval:

• An approval is withdrawn. A reviewer finds a problem with a document they approved, or new information casts doubt on it.
• A document expires. The passport the customer verified with reaches its expiry date.
• The provider changes its mind. Your identity verification provider places a hold or resets the customer in its own dashboard, for example after its own review.

If the platform does not connect these events to the transfers relying on the document, three bad outcomes follow: transfers sail through on evidence that is no longer valid; the payout partner refuses them later, after the customer has paid; or the console and the provider disagree in silence, and nobody can say which is right.

When a reviewer withdraws an approval or removes a document, the right outcome for each transfer depends on how far it has gone:

Two safeguards make this workable. First, the reviewer should see, before confirming, how many transfers the change will send back, so a single click never surprises operations. Second, the withdrawal should need a reason, and the removed document should be kept, not deleted, so an examiner can see what was there and why it went.

Expired documents are predictable, so they should never surprise anyone. Check expiry dates every night. When a document a customer relies on expires, treat it like a withdrawn approval: transfers that depend on it ask for a replacement, and the customer is asked for a new document before checkout refuses the old one, not after they have paid.

Tell the customer what to upload and why. "Your passport has expired; please add a valid ID to keep sending" gets a quicker response than a transfer that simply stops.

Your identity verification provider has its own dashboard, and its reviewers can act there. If those actions do not reach your console, your team works from a picture the provider no longer agrees with.

• A provider hold should reach the console and ask your compliance team to review, rather than being ignored or acted on silently.
• A provider reset should not undo your approval on its own. Raise an alert and let an officer decide; the provider's reset is information, not a verdict.
• A result delivered twice should be recorded once. Duplicate callbacks should not create a second customer document or trigger a second review.
• Keep the evidence: the provider's original verification record and the liveness recording, with the face-match score, from the moment they are produced.

A reviewer re-reading a file notices that the address on a customer's approved proof of address does not match their profile. The customer has three transfers in progress: one waiting for payment, one paid and waiting for payout, and one already paid out yesterday.

The reviewer withdraws the approval and gives a reason. Before confirming, the screen says two transfers will be sent back. Both go back to asking the customer for a replacement document; the customer is told what is needed and uploads a current utility bill the next morning. Once it is approved, both transfers return to where they were and continue. The transfer paid out yesterday is untouched: the decision applies to what has not left yet, and the reviewer notes the earlier payout in the file.

Without the link between the decision and the transfers, the paid transfer would have gone to the payout partner on the withdrawn document, and the partner might have refused it days later with the customer's money in limbo.

RemitSo connects KYC decisions to the transfers that depend on them. Your team still makes every decision on a document and decides what to do about transfers already paid out.

• Withdrawn approvals reach the money (since release 2026.08.8): withdrawing an approval or removing a document needs a reason and is kept, with removed documents under a Deleted tab. Before you confirm, the screen says how many transfers will be sent back. Transfers relying on it ask the customer for a replacement and return to where they were once one is approved. Transfers already sent to the partner or paid out are never pulled back.
• Expiry checked nightly: an expired document is treated the same way, and customers are asked for a new ID before checkout refuses the old one.
• Your provider and your console agree (since 2026.08.4): a hold made in the provider's own dashboard asks for compliance review; a provider reset never undoes an approval on its own (an alert goes out and an officer decides); a result delivered twice is recorded as a duplicate and not retried.
• Evidence kept: liveness recordings with the face-match score, and the provider's original verification record, kept from the moment they are produced.
• Document types under control (since 2026.08.9): switching off a KYC document type stops it being offered; a deleted type can be restored; both ask for a reason that is kept.
• Plain-language alerts such as "KYC reset at the provider", "KYC requires compliance review" and "KYC record switched off at the provider", sent to the people subscribed to them, and every call to an identity provider on the record.

See the admin features, read the release notes, or book a demo.