Launching a First-of-Its-Kind Card Programme with Visa in Four Months
Programme management, regulatory translation, and getting five card variants through Visa approval while threading Brexit. A case study in dependencies, not campaigns.
The Situation
Monolith (now token.com) wanted to do something nobody had properly done before: launch a card programme in partnership with Visa that bridged traditional payment rails with decentralised financial infrastructure. The ambition was significant. The execution was, by any measure, a stretch. And the number of moving parts that had to align, regulatory, logistical, design, operational, was enough to make most project managers walk away.
I was brought in to manage a substantial chunk of the programme. Specifically, I owned the approval and implementation of a new line of “portal cards”, five distinct card variants, each with different colour schemes, a restructured number format, and unique packaging requirements. The cards had to meet Visa’s exacting design standards. They had to be manufactured, imported, warehoused, and shipped to customers in countries with wildly different address formats. And the whole programme had to thread the regulatory complications created by Brexit, which split the service structure between UK and EU jurisdictions.
On top of the card programme, I was responsible for managing internal reporting on customer financial distress issues, negotiating comfort levels around on-chain provenance verification, and orchestrating consumer messaging for card shipments, expirations, and replacements. This was a programme management role that happened to sit inside a fintech company, not a marketing role, and it required thinking in dependencies, not campaigns.
What I Saw
The first thing I noticed was that the team was treating this as a series of independent tasks. Card design was one workstream. Packaging was another. Regulatory compliance was a third. Customer messaging was a fourth. Each had its own owner, its own timeline, its own set of assumptions. Nobody had mapped how these pieces connected, where a delay in one area would block progress in three others.
Complex programmes with multiple stakeholders and regulatory dependencies don’t fail because of bad ideas. They fail because of bad sequencing. If you do the wrong thing first, even by a week, the downstream consequences cascade. The Visa approval process, for instance, was the most constrained element in the entire programme. You couldn’t manufacture cards that hadn’t been approved. You couldn’t ship cards that hadn’t been manufactured. You couldn’t notify customers about cards that hadn’t shipped. Every step was dependent on the previous one, and any delay at the top of the chain pushed everything below it.
The second insight was about language. Monolith was a decentralised finance company trying to work with Visa, one of the most traditional financial institutions on the planet. The teams at Visa spoke compliance, risk, and regulatory frameworks. The teams at Monolith spoke blockchain, smart contracts, and on-chain verification. The vocabularies were different. So were the worldviews. Getting everyone to the same table and the same understanding was going to be as important as any technical work.
The third was about the Brexit split. Most people at the company were aware of it in principle. Very few had thought through what it meant in practice, that every customer touchpoint, every terms-of-service document, every data processing agreement, every communication template needed to exist in two jurisdiction-specific versions. A footnote in a project plan wouldn’t cut it. This was a parallel workstream that touched everything.
What I Did
My first action was to map the entire programme as a dependency chain. I identified the critical path, the sequence of events that had to happen in order, where a delay in any link would delay everything downstream, and the parallel workstreams that could run independently. This map became the single source of truth for the programme. Every team knew what they owned, what they were waiting on, and what was waiting on them.
The card approval process became five parallel workstreams rather than five sequential ones. Each of the five variants required separate Visa approval. Colour choices had to match Visa’s guidelines exactly. Even minor design changes required formal sign-off. The number format restructuring introduced additional complexity because it affected technical integration with Visa’s processing systems. By running these in parallel rather than sequentially, we compressed what would have been a twelve-month process into four months. That required detailed tracking, daily coordination with design and technical teams, and immediate escalation when any workstream fell behind.
The packaging logistics added another layer. Card boxes had to be designed, approved, manufactured, and imported. Then shipped to the designated warehouse and integrated into distribution. International shipping to countries with non-standard address formats required custom logistics solutions. I worked with operations to build a process that handled edge cases without slowing the standard flow.
For the Brexit service split, I built a compliance matrix that mapped every customer touchpoint to the applicable regulatory requirements for each jurisdiction. Terms of service, data processing agreements, communication templates, everything existed in UK and EU variants, and the matrix ensured nothing fell through the cracks. Legal reviewed each element, but the matrix meant they were reviewing a structured system rather than a pile of disconnected documents.
Customer messaging was a programme in itself. Card shipment notifications, expiration reminders, replacement instructions, each required templates that were clear, compliant, and consistent across jurisdictions. I designed the messaging framework to be modular, so jurisdiction-specific elements could be swapped in without rebuilding communications from scratch. New country? Swap the module. Don’t rebuild the system.
For the on-chain provenance negotiations, I built a presentation framework that translated decentralised concepts into language that Visa’s compliance and risk teams could evaluate using their existing frameworks. I wasn’t trying to convince them that blockchain was the future. I was showing them that what we were doing could be assessed against criteria they already had. That reframe changed the conversation from “we don’t understand this” to “we can evaluate this.”
Internal reporting on customer financial distress required a framework that met regulatory requirements without creating information overload. The reports were structured to surface practical patterns, not just data, but the “so what”, so the team could address issues before they became compliance problems.
What Happened
The card programme launched successfully after a four-month execution period. All five portal card variants were approved, manufactured, and distributed. The programme established a concrete precedent for integrating traditional financial infrastructure with decentralised financial technology, a model that other companies in the space have since referenced.
The parallel workstream approach reduced the programme timeline by approximately eight months compared to sequential execution. That acceleration was the difference between being first to market and being one of many. In fintech, being first to market with a credible product is a credibility signal with partners, investors, and regulators, not just a commercial advantage.
The compliance matrix I built for the Brexit service split became the company’s standard framework for multi-jurisdiction regulatory management. It was applied to subsequent product launches and partnership discussions, saving the team from rebuilding regulatory infrastructure for every new initiative. That’s the kind of asset that doesn’t show up in quarterly metrics but compounds in value over time.
The customer messaging framework delivered strong delivery rates and customer satisfaction scores across both UK and EU customer bases. The modular design meant new jurisdictions could be added without rebuilding the communication infrastructure from scratch.
The on-chain provenance framework opened a partnership channel with traditional financial institutions. By translating decentralised concepts into traditional risk and compliance language, I gave those institutions a way to evaluate what Monolith was doing, leading to additional partnership discussions that wouldn’t have happened if we’d kept speaking our own language.
The programme’s success was referenced in industry coverage as a model for how traditional and decentralised financial companies could work together.
What I’d Do Differently
The biggest lesson was about stakeholder alignment at the start. I mapped the dependency chain early, which was the right call, but I didn’t invest enough time in getting every stakeholder to internalise it. Some teams treated the dependency map as a project management artifact rather than a living constraint. When a team doesn’t fully internalise that their delay blocks three other teams, they optimise for their own timeline rather than the programme’s. I’d spend more time in week one building shared understanding of the critical path, not just showing the map, but making everyone feel the consequences of a broken link.
I’d also push for earlier engagement with Visa’s compliance and risk teams. We brought them in at the right point in the process, technically, but we could have started the language-translation work earlier. The on-chain provenance framework took longer to build than expected because we were learning what Visa needed to see at the same time we were building it. If I’d started those conversations in the first month rather than the second, we’d have saved weeks.
The Brexit compliance matrix was a success, but I’d build it as a digital tool rather than a document. It worked as a spreadsheet, but a live system that flagged jurisdiction-specific requirements automatically would have been more reliable and less dependent on someone remembering to check it.
Finally, I’d document the decision-making process more aggressively. In fast-moving programmes, decisions get made in conversations, Slack threads, and hallway discussions. Six months later, nobody can remember why something was done a particular way. That’s fine until you need to replicate the programme or explain it to a new partner. Write it down. Every time. You’ll thank yourself later.