A working bank connection does not make a fintech product ready for launch. Readiness begins when a real merchant can satisfy every requirement between account creation and the first live transaction.
Consider Sami, an illustrative composite of a Tunisian fintech founder. At 4:20 on Friday afternoon in Tunis, he was holding his phone over an untouched coffee while the dashboard showed exactly what his team had spent weeks trying to achieve: the bank connection was active, test requests were returning correctly, and the transaction state matched their internal records.
The first merchant still could not go live.
Friday exposed the missing part of the product
The merchant, Leila, ran a small online homeware business. She had agreed to be the first live account because she already knew Sami and understood that the product was early.
Her willingness had carried the team through the build. It could not carry her through activation.
One required business document no longer matched the trading information she used online. A second requirement depended on evidence she did not keep in a form the activation process could accept. The team could explain each field, but explanation did not change the status on the screen.
Pending.
Leila had planned to use the new payment flow for orders promoted that weekend. If activation failed, she would return to her existing process. Sami would lose the launch window and, more seriously, his only evidence that the integration worked outside his team’s test environment.
For a few minutes, there was no engineering task to assign. The connection worked. The logs were clean. Another deployment would change nothing.
This is the moment founders often discover that they have built the technical route but have not yet built the path a customer can complete.
Activation requirements belong inside product discovery
Sami’s team had treated merchant activation as a final compliance step. Their planning began with the bank documentation, moved through authentication and transaction handling, then ended with a successful test.
That sequence made sense from the integration outward. It failed from the merchant inward.
Leila did not experience an API connection. She experienced a request to assemble records, resolve mismatched details and understand why evidence that looked reasonable to her was insufficient. Every unresolved requirement increased the chance that she would abandon the new product before reaching its core value.
The earlier discovery question should have been concrete: “Can our first merchant produce what this flow asks for, in the format it asks for it?”
That question needs an answer before the team commits its launch date. A founder can test it with one merchant and a rough checklist. Sit beside them while they gather the information. Note which terms require explanation, which documents are missing, who controls each record and what happens when two sources disagree.
This is product validation at the point where regulation, operations and customer reality meet. The same discipline appears in Femi’s decision to validate Ada’s workflow before building further: the decisive evidence comes from watching a specific person attempt the work, rather than confirming that the system performs as designed.
A smaller launch can reveal more
With the weekend campaign approaching, Sami had three choices. He could push Leila to find replacement documents, seek an exception he could not promise, or redefine what Friday’s launch needed to prove.
He chose the third.
The team stopped calling the bank connection “launch-ready” and separated three states that had previously been collapsed into one:
- The technical connection could exchange the expected information.
- The merchant could submit the required activation evidence.
- The merchant could complete the full live transaction path.
That distinction did not rescue the weekend promotion. Leila kept her existing payment process, and the new product missed the public launch Sami had pictured.
It did rescue the next decision.
Instead of adding features on Monday, the team mapped every activation requirement to an owner, an acceptable form of evidence and a failure path. They also recruited the next test merchant based partly on whether that business could attempt the full activation journey. The work resembled the decision in Emeka’s missing compliance evidence: when required evidence is absent, narrowing the claim is safer than pretending the whole flow is ready.
Define “live” before the build begins
For an early fintech product, “the integration works” is a technical statement. “A merchant can go live” is an operational outcome involving the product, the institution and the merchant’s actual records.
Those statements need separate acceptance criteria.
Before building the next connection, write down the first merchant’s path from initial interest to first completed transaction. Place every external requirement on that path. Then test the requirements with the merchant before using technical completion as a launch signal.
Ask who has each document. Ask what could be outdated or inconsistent. Ask which failure can be corrected by the merchant, which needs human review and which stops activation entirely. If the team cannot answer, the unresolved work belongs on the launch plan.
On Monday morning, Sami’s dashboard still showed a functioning connection. Beside it sat a new activation worksheet, filled with the obstacles Leila had uncovered on Friday. The product had fewer claims attached to it, but the team finally knew what “ready” had to mean.
Comments
No comments yet.