Payments Watch Source previously reported a source-attributed allegation that Fortris processed payment flows for offshore betting businesses serving unauthorized U.S. customers. Against that risk profile, a new Fortris asset, wallet, cashier feature, transfer route or country should not go live on the strength of a product roadmap alone. It needs a dated regulatory gate that records what the function does, who performs it and what controls are ready.
Fortris markets modular payment capabilities, governance workflows and fiat and stablecoin operations. Modularity accelerates deployment but also makes boundaries easier to change incrementally. Adding a withdrawal option, a new destination, a customer balance, an automated conversion or a different signing policy can alter the functional and regulatory analysis even if the product name remains unchanged.
The gate begins with a product truth statement
Before release, the product owner should describe the feature in operational terms: who the user is, whose money is involved, where it is held, what instruction is created, who can approve or reject it and when settlement becomes final. Legal and compliance teams can then classify custody, payment initiation, transmission, exchange, safeguarding, consumer or gaming implications in every intended jurisdiction. The answer should cite the licence, exemption, partner authority or reason the activity is treated as unregulated technology.
A partner approval is a separate gate. Banks, exchanges, custodians and liquidity providers should confirm the exact use case, merchant category, countries, assets and transaction volumes they accepted. Security should confirm key management and access controls. Compliance should demonstrate that sanctions, wallet, merchant, territorial and behavioral scenarios have been tested with realistic data. Operations should prove reconciliation and rollback. No single signature should stand in for these different judgments.
Paystack’s launch sequence is the benchmark
Reports from Techpoint Africa and Business Post Nigeria placed Paystack’s launch of Zap in March 2025 and a reported ₦250 million CBN fine in late April. The outlets said the regulator viewed the consumer transfer product as beyond Paystack’s processor permissions or launched without required approval. A public CBN decision was not located, making those details attributed reporting, not an independently reviewed adjudication.
Paystack’s launch post described the consumer problem and product experience. Later Zap material said a regulatory review was completed before the product returned with changes. For Fortris, the lesson is not that every feature everywhere requires the same approval. It is that launch records should demonstrate the jurisdiction-specific analysis before customers and funds encounter the function, and should reopen the analysis when the operating model changes.
Board evidence and stop authority
Management should receive a concise launch certificate listing the accountable Fortris entity, regulated partners, permitted countries and customers, prohibited uses, monitoring scenarios, safeguarding structure, record-retention plan and named incident owner. Material launches should include an independent challenge by someone outside the revenue line. The governing body or designated committee should see unresolved objections and any decision to accept residual risk.
The gate also needs teeth. A launch date cannot automatically override missing partner confirmation or failed control tests. The record should name who can say no, who can grant a limited exception, its expiration date and the evidence required to remove it. Post-launch monitoring should compare observed activity with assumptions: user geography, merchant type, asset mix, balances, withdrawal behavior and exception volume.
Release is only the first control point
The go-live record should define measurable early-warning thresholds for the first weeks of operation: failed reconciliation, unsupported countries, manual overrides, delayed withdrawals, alert volume and partner rejections. Crossing a threshold should trigger a named response, from limiting volume to disabling the function. Otherwise post-launch monitoring becomes observation without intervention.
Fortris should preserve the configuration and legal basis that existed on each release date. That archive matters when a later incident requires investigators to determine what users could do, which controls were active and which partner accepted the route. Current documentation cannot reliably reconstruct a product that changed several times.
Internal audit should later compare approved assumptions with production evidence and report launches where commercial deadlines, incomplete testing or undocumented partner changes displaced the original control design.
Customers should receive notice when a change alters permitted use, responsible entity, safeguarding route or available remedy. The notice should identify the effective date and the evidence supporting continued operation.
Fortris has not been shown by the Paystack reports to have launched an unauthorized product. The relevant test is whether its own files can show that classification, authorization, controls and partner acceptance preceded each release. A credible gate leaves a reproducible decision trail. A post-launch explanation merely shows that the organization learned how to describe a decision after the exposure already existed.