If a vendor cannot map its compliance product to the specific CBN requirements it claims to cover, the launch decision has already changed. Protecting the date now means accepting a control gap that nobody can explain, test or defend.
At 4:17 PM on Friday, Emeka stood beside a whiteboard in a Lagos office, holding the launch checklist his team had revised twice that week. He is a composite founder, drawn from a pattern I have seen across regulated product work. Monday’s release would open a new payment flow to a small group of merchants. The compliance vendor had marked its integration complete.
One row remained blank: requirement, product control, evidence.
The blank row changed the decision
Emeka asked the vendor a narrow question: “Which CBN requirement does this rule implement, and what evidence would we show if someone challenged it?”
The first answer described the product’s monitoring capabilities. The second pointed to a dashboard. After another call, the vendor sent a policy document that used phrases such as “regulatory alignment” without connecting a single requirement to a specific rule, alert or review step.
That left two possibilities. Either the product covered the requirement and the vendor could not demonstrate how, or the product did not cover it. Monday’s launch was exposed under both.
Emeka’s engineering lead wanted to proceed with tighter transaction limits. His operations lead argued for a manual review queue. Both ideas could reduce immediate exposure, but neither answered the missing question. A smaller unidentified gap remains unidentified.
The worst outcome was no longer a delayed launch. It was launching a payment process the team believed was compliant, then discovering during an incident or review that the belief came from a sales presentation rather than a tested control.
By 5 PM, the office had thinned out. Emeka still had one weekend, but time alone could not produce an answer the vendor did not possess.
Compliance claims need a traceable chain
A compliance product should allow a team to follow a requirement through four connected points:
- The applicable requirement is written in language the team can identify.
- A product control addresses that requirement.
- A test shows the control behaving as expected.
- Stored evidence shows what happened when the control ran.
The chain matters because each group sees a different part of the system. Legal or compliance interprets the obligation. Product decides where it belongs in the flow. Engineering implements the behaviour. Operations handles the exceptions. A vendor may supply one part, but the founder still owns the decision to launch the whole process.
This is why a feature demonstration cannot settle the question. A dashboard can show alerts without proving that the right conditions create them. A policy document can sound complete while leaving product behaviour undefined. A certification may support vendor selection, but it does not map your customer journey to your obligations.
The same boundary problem appears when a chatbot hands a customer into a regulated process. The handoff looks like a product detail until nobody can say which system owns the next decision.
Replace the launch debate with an evidence test
Emeka stopped asking whether the team felt comfortable launching. Comfort was impossible to compare across legal, engineering and operations.
Instead, he wrote a short evidence test for the vendor:
For each requirement in scope, identify the corresponding control. Show the configuration that activates it. Demonstrate one accepted case, one rejected case and one case sent for review. State what evidence the system retains. Name any part the customer must perform outside the product.
This changed the weekend conversation. The question became measurable: could the vendor complete the mapping and pass the tests before the release decision?
The team also separated controls into three groups. Some were confirmed and tested. Some required work on Emeka’s side. The disputed controls had no traceable evidence. Only the third group could block the launch, which prevented one unanswered question from turning into a vague argument about the entire integration.
Late on Saturday, the vendor supplied partial mappings but could not show how one disputed rule affected the transaction flow. That was enough information to make the call. Emeka removed the affected flow from Monday’s release and kept the parts whose controls the team could demonstrate.
He did not preserve the original launch. He preserved a launch he could explain.
Monday became smaller and defensible
On Monday morning, the release checklist had fewer rows. The disputed payment path was disabled, the manual workaround had been rejected because its ownership was unclear, and the vendor had a dated list of evidence still required.
The product team now had a boundary it could test. Operations knew which cases could enter the released flow. Compliance could point from each covered requirement to a control and from each control to evidence. The missing path stayed closed.
That is the practical value of requirement mapping. It turns “the vendor says we are covered” into a chain your team can inspect before customers, regulators or an incident force the inspection.
A launch date creates pressure because it is visible. An unmapped control stays quiet. When the two conflict, I would protect the decision I can defend later.
At 9:06 AM, Emeka watched the first merchant complete the smaller flow. The disabled path was still visible in the release plan, marked with one sentence: reopen only after the evidence test passes.
Comments
No comments yet.