The Same Customer, Verified Again, Because a Calendar Said So

The cost nobody budgets for

Onboarding gets modelled. A finance team can tell you what it costs to bring a customer in.

Re-verification usually does not get modelled, because it arrives as maintenance rather than as growth. Yet it lands on the same review queue, at the same per-case cost, for people the business already knows.

And it is triggered by a calendar or a rule change rather than by anything the customer did.

What actually sets off a re-check

A periodicity rule. Higher-risk relationships get refreshed on a shorter cycle than lower-risk ones. Nothing has happened; the clock ran out.

A rule change. A supervisor's expectations move, an internal risk model is revised, and a whole cohort is re-examined at once. This is the one that produces a spike rather than a trickle.

A change in the customer. A new jurisdiction, a new product, a threshold crossed, a document that expired.

A dormancy wake-up. An account that sat idle becomes active, and the file is now old enough to distrust.

Most of these are predictable. Almost none of them are cheap.

Why the second check costs nearly as much as the first

Because it usually is the first check, run again from the beginning.

The customer is asked to photograph the same document, present the same face, and wait for the same queue. The business already holds a file establishing exactly this, and cannot rely on it, because the file has aged past what its own policy accepts.

So the expensive part is not the checking. It is that nothing carries forward.

Where a portable credential actually bites

This is the case reuse was designed for, and it is worth being precise about why.

An identity credential carries a validity structure: the standard our credentials follow has explicit fields for when a credential becomes valid and when it stops being valid. A relying party can key a refresh policy to that structure rather than to a date in its own spreadsheet, and a customer who has been re-verified anywhere can present something current instead of starting again.

That does not make the decision for you. Which is the important part.

The line we will not cross

We are not the regulated entity, and the re-verification decision is not ours.

When a customer needs re-checking, on what cycle, and to what standard, belongs entirely to the bank, the electronic money institution or the exchange holding the obligation. A vendor that offers to make that decision is offering to take a position it cannot be accountable for.

And accepting a reused credential does not discharge that obligation either. What changes is the cost of satisfying it, not whose obligation it is.

What to ask any vendor

"What share of my checks are re-checks?" Ask your own team first. Most businesses have never separated the two, and the answer decides whether any of this matters to you.

"Does a reused credential tell me when it stops being trustworthy?" A credential without an explicit validity structure pushes that judgement back onto you.

"Who decides when a customer needs re-verifying?" The only correct answer is you. Anyone else answering has misunderstood their position.

"What does a rule change cost me?" The spike, not the steady state, is what breaks a budget.

Where this leaves a decision

If your re-check volume is small, this is not your problem and the automation rate on first-time customers is where your money is.

On legal advice

Nothing here is legal advice.