Launch checklist template for Fintech

The launch checklist with the rows a regulated financial product needs before a campaign starts: every claim cleared and referenced, the disclosure present in the ad and on the page, the delivery restricted to authorised markets, and the landing page carrying the current terms.

Everything else is the general checklist, unchanged. One row per check, with an owner by name, a due date relative to the start, an honest blocking flag, a verification method and evidence kept.

Use it before every campaign, including small ones. The cost of an error here is not a wasted week of budget; it is advertising that ran before it was cleared, which turning it off does not undo.

Use it again whenever a rate, a fee or a term changes mid-flight, because that is a launch of new creative under a new review.

Most launch problems are recoverable. A broken pixel wastes a week. A wrong budget is corrected. A bad audience is rebuilt.

Creative that ran before it was cleared is different, because it has already reached people. Pausing the campaign stops more of it and undoes none of it, and the record of what ran is whatever your systems happened to keep.

That asymmetry is what shapes this version of the checklist. The review row blocks, without exception, and it is verified against the review record rather than against somebody's recollection of a conversation. Everything else on the list is ordinary diligence; this one row is the reason the list exists.

The verification is mechanical and it is worth doing mechanically: list every ad that will run, with the review reference it carries, and check each reference against the review record and its date.

Two failure modes show up. The first is an ad with no reference, usually because it was duplicated from something older during a rush. The second is an ad whose reference is real but predates a change to a rate, a fee or a term, which makes the cleared wording stale even though the review exists.

Both are invisible in an ad account and obvious in a list. Keep the list as the evidence for this row, with the reviewer's confirmation attached.

The disclosure check is not a check of the asset. It is a check of the rendered ad, on the actual placement, and of the landing page as a customer sees it.

Disclosures fail in rendering rather than in design. Text is truncated by a placement's character limit. A fee summary that sat above the fold on a desktop layout sits below it on a phone. A template drops a footer. A video's overlay is covered by the platform's own interface in one format and not another.

So the verification is to look at the live preview on each placement and to open the page on a phone. Screenshots are the evidence, and they are worth keeping because they are the only record of how the thing actually appeared.

The jurisdiction row confirms that delivery is restricted to markets the product is authorised in, checked in the settings, with a screenshot.

The reason it needs its own row is that this restriction usually lives in one delivery setting, and delivery settings are edited routinely by people who are not thinking about authorisation. An audience expansion, a duplicated campaign, a platform default that re-enables a setting on save — any of those can widen delivery quietly.

Confirming it at launch does not prevent later drift, which is what the account audit is for, but it does establish that the campaign started correctly and it takes two minutes.

The landing page row checks that the page states the current rate, fee and terms, in the words the review cleared, with the disclosure the review specified.

Pages drift independently of ads. A rate is updated in the product system and on one page but not on the campaign page. A fee summary is moved during a redesign. A comparison that was accurate last quarter is not re-checked. The ad is then correct and the journey is not, which is the same problem from a customer's point of view.

Open the page as a customer, on a phone, following the actual ad link with its parameters. That last detail matters: a redirect can change which page version is served.

A retargeting audience built from people who started an application is defined by a financial circumstance, and creative cleared for prospecting is not automatically cleared for it.

So the checklist carries its own row: retargeting ads carry their own review reference, and the wording is a reminder rather than a reference to the reader's situation. It is a small row and it catches a mistake that is otherwise made by duplication, in a hurry, on launch day.

In this category the evidence column is not administrative tidiness, it is the record.

The question that eventually arrives — what was running, where, under which review, on which date — is answered by what was kept at the time. Screenshots of rendered ads, the list of ads and references with the reviewer's confirmation, the delivery settings, the page as it appeared. All of it is trivial to capture on the day and impossible to reconstruct later.

So the evidence goes somewhere durable and shared rather than into a personal folder, and it is named with the campaign and the date. A checklist whose evidence lives on one laptop is a checklist that produces nothing when the laptop's owner changes jobs.

Seven checks. Every row has an owner by name and a due date relative to the start. Every live ad's claim appears in a current review, by reference, and none of those references predates the last change to a rate, a fee or a term. The disclosure is present in the rendered ad on each placement and on the page as a customer sees it. Delivery is restricted to authorised markets, with a screenshot. The landing page states the current terms, checked by following the real ad link. Retargeting ads carry their own cleared creative. And every completed row has evidence attached, because in this category the evidence is the point.