What happens if a merchant corrects information after submitting?
A submitted application locks read-only. Your team reopens it and the merchant corrects it in place, pre-filled. The file your payment partner reviews stays the file you approved, and every change carries an author and a timestamp.
In detail
A submitted application locks read-only. The merchant cannot change it on its own, which protects the file your team reviewed and approved.
When a correction is needed, your team reopens the application. The merchant then corrects it in place, with the form pre-filled with its previous answers, so it only changes what needs changing. Once resubmitted, the application locks again.
Why the file stays reliable
- The file your payment partner reviews stays the file you approved.
- Every change carries an author and a timestamp.
- Documents are never overwritten: a replacement lands as a new version, and earlier versions stay on record.
This matters most when an application has already been sent to a payment partner. A partner should never discover that data changed under it without a trace. With a controlled reopening, your team decides when a correction is acceptable, and the history shows what changed, when and by whom.
The same logic applies to follow-up questions. When a partner or an analyst needs more information, the request goes through the merchant's file and the answer lands there, on the record. The merchant never has to restart its KYB to correct one detail, and your audit trail shows the full path from first submission to approval.