# Test plan — Fintech

The test plan with three columns a regulated financial product needs: which product the test runs against, which claim the variant is putting under test, and the review reference that cleared both arms of it.

Everything else is the general test plan, unchanged. One hypothesis with a because in it, one variable, a named control, a minimum run, a read date set in advance and a decision rule for every outcome.

## How to use it

1. Copy this file, or the CSV version if you would rather work in a sheet.
2. Write the hypothesis before the variant, and make sure it contains a because.
3. Name one variable. If there are two, that is two tests.
4. Set the primary metric, the minimum run and the read date before anything is built.
5. Write the decision rule for every outcome, including the one where nothing moves.
6. Leave Result blank until the read date, and then fill it in whatever it says.
7. Keep the finished rows. A year of them is worth more than any single test in it.

## The columns

**Test ID** (Text). A short stable identifier that travels onto the creative file, the ad name and the review record, so a finding can be tied to the wording that was cleared for it.

**Hypothesis** (Text). What you believe and why, with a because in it, and here the reason is usually about applicant quality: leading with the fee position will raise funded accounts because the current ad attracts people who do not qualify.

**Variable** (Text). The single thing being changed, and in this category it is almost always a claim. Two claims in one variant means a review that clears both and a result that explains neither.

**Control** (Text). What the variant is compared against, named exactly, including its review reference and the page it points at. A control whose page has drifted is not the control that was agreed.

**Variant** (Text). What is being tried, described so somebody could build it, and written as the exact claim that will go to review rather than as a paraphrase of it.

**Audience** (Text). Who sees the test, identical on both sides and inside the same authorised market. A test whose arms deliver differently across markets is not comparable and may not be permissible.

**Where it runs** (Text). The platform, campaign and placement the test lives in, and whether the placement can carry the disclosure the variant's claim requires at a readable size.

**Primary metric** (Text). The one number this test is decided on, which should be a funded account or an approved application. A test read on applications will adopt whichever variant attracts people who are declined.

**Minimum run** (Text). The shortest run before anybody looks, long enough for funded outcomes to land rather than for applications to accumulate, which makes tests here slower by construction.

**Read date** (Date (YYYY-MM-DD)). The day the result is read, set in advance and after funded accounts from both arms have settled. Reading early answers a different question confidently.

**Decision rule** (Text). What each outcome means, written before the test starts, including what happens when the variant lowers cost per application and lowers the approval rate with it.

**Owner** (Text). The person who builds the test, reads it on the read date, and records a refused claim as a result rather than dropping the row.

**Result** (Text). What happened and what was decided, written on the read date, including a claim that review refused or narrowed before the test could run. Blank until then.

**Product** (Text). The financial product this test runs against. Approval and funding rates differ by product, so a result from one rarely transfers to another without being re-read.

**Claim under test** (Text). The claim the variant is making, written plainly. It is what goes to review, and naming it here is what turns a review into an hour rather than a round of rework.

**Review reference** (Text). The reference that cleared both arms of this test, with its date. A test whose variant is not cleared cannot start, whatever the hypothesis is worth.

## The test plan

| Test ID | Hypothesis | Variable | Control | Variant | Audience | Where it runs | Primary metric | Minimum run | Read date | Decision rule | Owner | Result | Product | Claim under test | Review reference |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |

## Before you commit it

- Every row has a hypothesis with a because in it.
- Every row names the claim the variant makes, in plain words.
- Both arms carry a review reference with a date.
- The primary metric is a funded account or an approved application, not a click.
- The read date allows funded accounts time to land.
- The decision rule covers the outcome where nothing moves.
- Every finished row has a result, and refused claims are recorded too.