CRO for Fintech Funnels That End in a Verification Check

Run a normal CRO programme against a lending or account-opening funnel and you can improve the reported number while making the business worse off. That is the whole problem, and it sets everything else on this page.

The conversion you can see and the one you are paid for

The chain runs: visit, application started, application submitted, identity and eligibility checks, approved, funded, still active after ninety days. Testing tools measure step two or three. The business earns at the far end.

Those two ends are joined loosely enough that pushing the near one can drag the far one down. A stronger headline pulls in people the checks will decline. A softer eligibility line at the top of the form brings applicants who never had a chance. Both show up as a lift on Monday and as nothing at all in the quarter.

So the analysis plan names the downstream outcome up front. Either as the primary metric, or as a guardrail with a threshold that stops the rollout. And the readout waits for it. That makes tests slower here and fewer per quarter. The realistic count goes in the scope document, so the number is agreed before anyone is disappointed by it.

Sort the hypothesis list by review cost

A four-headline test is four pieces of copy for approval plus the control. That arithmetic does not exist in other sectors and it changes which hypotheses are worth queueing.

Structural changes carry no product claim. Field order, and one question per screen. Where the document upload sits, and when the credit check is explained. Saving a half-finished application, so somebody can come back to it on a laptop. Those clear review quickly and they are where we start.

Claim-shaped changes, anything touching rate framing, comparisons, guarantees or what the product is described as doing, are expensive per cell. We batch them into a single review round with the rendered variants side by side, and run them as one test with fewer cells. The trade is that only a larger effect is detectable. An underpowered five-cell test that took six weeks to approve is the worst outcome available.

What you are not allowed to delete

Standard advice is to cut fields until the form is short. In your funnel a field is there because a check downstream consumes the value. Removing it moves the work to a person chasing the customer by email two days later. That is worse than the friction it saved.

What is left is real. Ask the easy questions while momentum is high. Explain each awkward field where it is asked and say what happens to the answer. Split the interruptions onto their own screens. Document upload, identity capture, bank connection. A drop-off then tells you which check lost the customer, and does not average them into one number. Then instrument per field, because “the form converts at eleven percent” is not a finding anybody can act on.

Keep the assignment record

Variant assignment is written into your own server-side event record with the version of the copy that was live: which visitor, which cell, which date. A third-party testing tool keeps its data for as long as its own retention setting says. That setting was chosen by someone optimising for storage cost.

The question that makes this worth doing arrives later, from a complaint, an audit or a reviewer. What did this person see when they opened the account? “We were running a test that month” is not an answer.

When the arithmetic says do not test

Power gets calculated on the downstream outcome here, which is a fraction of the visible one. Run that arithmetic honestly and a good part of the hypothesis list disappears. The test would need more approved accounts than you will originate this year.

When that happens we say so and the work changes shape. Defect hunting across devices, session review on abandoned applications, interviews with people who dropped at the identity step, instrumentation that is currently lying to you. None of it needs statistical power, and all of it is cheaper than a year of tests that cannot resolve anything.