Blog

I have managed projects across borders for most of my career. Digital branding in Bahrain, mobile platforms in Saudi Arabia, e-commerce infrastructure in the UAE. The lesson I kept learning was the same every time: distance is rarely the hardest problem. Culture, regulation, and the speed at which each country moves through its own approval process is where projects live or die.

When I joined IDCentriq and took on the Senior Project Manager role for its holding group and its subsidiary PaymentsCo, I stepped into something that made every cross-border project I had managed before look straightforward. Suddenly I was coordinating legal teams, biometric technology vendors, financial institution partners, and regulatory bodies across Jordan, Bahrain, Saudi Arabia, and the UAE, all inside a single project lifecycle.

This article shares what that experience taught me. Not the version you find in PMP textbooks, but the real patterns. What breaks, what saves you, and what needs to be redesigned from the ground up when multi-country means multi-regulator.

1. Why Multi-Country FinTech Projects Break Standard PM FrameworksStandard project management frameworks assume that the biggest variable is your team. Get the right people, align on scope, manage the risk register, and hit the milestones. In regulated FinTech, especially in the MENA region, that assumption fails at almost every turn

   Here is what actually changes:

   • Timelines are not owned by your team. A licensing milestone can be delayed by a regulator reviewing hundreds of pages of compliance documentation. No sprint velocity calculation accounts for that.
   • Scope is negotiated with external authorities. In digital identity deployments, what you are allowed to capture, store, and verify differs between Jordan, Bahrain, and the UAE. The product itself must flex to the regulatory envelope of each market.
   • Stakeholder maps are institutional, not individual. You are not just managing a client relationship. You are managing relationships with financial institutions, government bodies, and technology certification authorities all at once.
   • Risk is asymmetric. A compliance failure in one country can freeze operations in all countries if the brand is shared or the platform architecture is centralised.

   The project manager who walks into this environment with a standard Gantt chart and a RACI matrix will not fail because of lack of effort. They will fail because the tools were not designed for this complexity.

   The most dangerous assumption a Project Manager can bring into a regulated FinTech project is that the deadline is set by the team. It is not. It is set by the slowest regulatory authority in the chain.

2. The Regulatory Landscape Across Jordan, Bahrain, Saudi Arabia and the UAEEach MENA country has its own financial regulatory architecture, and each one approaches digital identity and payment products with a different philosophy. Understanding these differences is not just a legal task. It is a project management task, because these differences directly determine your critical path.
   

   Jordan

   The Central Bank of Jordan has been increasingly open to digital financial infrastructure, but it moves through a deliberate approval process. Projects involving digital identity linked to payment initiation require clear documentation of data residency and biometric data handling. The PM’s role here is largely documentation-heavy: preparing submission packages, tracking revision cycles, and maintaining relationship continuity with the regulatory liaison.

   Bahrain

   Bahrain’s Central Bank has positioned the Kingdom as a FinTech hub, and its regulatory sandbox framework is one of the more accessible in the region. That said, accessible does not mean fast. The sandbox process has defined gates, and each gate requires evidence packages. The good news is that the CBB is genuinely technically informed. Meetings tend to be substantive rather than ceremonial.

   Saudi Arabia

   SAMA operates at a scale that changes the dynamic entirely. Review cycles are longer, documentation requirements more extensive, and the number of internal approvals within partner financial institutions adds another layer of waiting time. Projects in KSA need generous buffers in every milestone that touches SAMA engagement.

   UAE

   The UAE has perhaps the most sophisticated digital infrastructure in the region, but also the most fragmented regulatory landscape. CBUAE at the federal level, ADGM and DIFC with their own frameworks, and emirate-level considerations on top of that. The PM’s job in UAE deployments is mapping which regulatory body owns which component of your product and making sure you are not caught in jurisdictional ambiguity.
   The practical output of understanding this landscape is a regulatory timeline overlay on your project plan. A separate track that runs in parallel with your technical delivery track and drives the critical path far more often than your engineering velocity does.

3. Managing Legal, Technical and Business Teams at the Same TimeOne of the structural realities of digital identity and payment platform deployments is that you are managing three teams that speak fundamentally different languages, operate on different time scales, and define success differently.

   Legal teams think in terms of risk mitigation, contractual coverage, and regulatory precedent. Their timelines are driven by review cycles, not sprints. Technical teams think in systems, interfaces, and delivery increments. Business teams think in pipeline, revenue, and relationships. The PM sits at the intersection of all three, not as a translator, but as an orchestrator.

   What I have found works in practice:

   • Weekly syncs with a shared dashboard showing status across all three tracks, not just technical progress
   • A single source of truth for NDA status, agreement versions, and licensing document submissions. In a multi-country legal environment this is not a nice-to-have. It is the PM’s most critical artefact.
   • Escalation protocols agreed before they are needed. When legal blocks technical, or when a regulatory delay threatens a business commitment, you need a pre-agreed escalation path that does not require a new decision every time.
   • Separate risk registers for technical risk and regulatory or legal risk, plus a third for the intersections between them.
4. Proof-of-Concept Phases in Identity and Payment PlatformsPoCs in this space are not prototypes. They are regulatory instruments. A PoC for a biometric authentication integration with a financial institution is partly a technical demonstration and partly a compliance evidence package. The PM who treats it only as the former will arrive at the production decision gate without the documentation the regulator needs.

   What a strong FinTech PoC needs to prove, beyond technical feasibility:

   • Data handling compliance. Where is biometric data stored? For how long? Under what security standard? Who has access?
   • Failure rate benchmarking. What is the liveness detection failure rate? What happens to a user who fails verification three times?
   • Integration stability. Can the identity layer communicate reliably with the payment authorisation layer under real transaction volumes?
   • Rollback capability. If the platform fails post-deployment, what is the recovery path and how does it affect users mid-transaction?

   Managing a PoC with this scope requires the PM to own not just the project plan but the evidence architecture. You need to know in advance what documentation the production gate will require, and build the PoC to generate that evidence.

5. Adapting Agile Sprints When Compliance Is a Deliverable
   Agile’s core promise is that working software is the primary measure of progress. In a regulated FinTech environment, working software that lacks the compliance documentation to be legally deployed is not progress. It is a liability.
   The adaptation I have found most effective is treating compliance documentation as a first-class story in the sprint backlog. Not a task or a sub-task. A proper story, with acceptance criteria, a definition of done, and an owner.

   This means:

   • Regulatory submission packages are sprint deliverables with the same priority weighting as feature releases.
   • Sprint planning explicitly accounts for documentation review cycles in the Definition of Done.
   • Velocity is measured against a combined metric: features delivered and compliance gates passed, not features alone.
   • Regulatory hold periods are modelled as explicit sprint states, not as interruptions to the backlog, but as a recognised project phase with its own workflow.

   If your Definition of Done does not include ‘regulatorily submittable’, your sprint output is incomplete by definition in a FinTech context.

6. NDAs, Agreements and Licensing: The Invisible PM Workload

   In standard project management, agreements are a pre-project activity. In multi-country FinTech deployments, they are an ongoing project activity that never fully stops.

   Over the course of a single deployment cycle, a PM in this space will typically manage:

   • Multiple bilateral NDAs with technology partners, financial institutions, and regulatory sandbox participants
   • Licensing applications across multiple jurisdictions, each with different document requirements and review timelines
   • Partner onboarding agreements that have technical annexes requiring PM sign-off on architecture specifications
   • Amendment cycles as product scope evolves during deployment and regulatory feedback requires product adjustments

   The PM who does not build a disciplined agreement tracking system will lose visibility at the worst possible moment. A living document showing every agreement, its status, its expiry, its renewal triggers, and the party responsible for each action is not glamorous work. But it will block your project if you treat it as someone else’s problem.

7. Key Takeaways and a Framework You Can Use

   If there is one principle I would distil from all of the above, it is this: in multi-country FinTech project management, the critical path is almost never where your engineers are working. It is in the regulatory engagement track, the legal documentation track, or the partner alignment track.

   A replicable framework for these deployments:

   • Build three parallel project tracks from day one: technical delivery, regulatory and legal, and partner and business. Manage them as equal tracks, not as a main track with two supporting ones.
   • Create a regulatory timeline overlay that maps every jurisdiction’s known approval cycles against your delivery milestones. Identify which approvals are on the critical path before the project starts.
   • Treat compliance documentation as sprint deliverables with the same sprint velocity accounting as features.
   • Invest in a single source of truth for agreements. One document that every team can reference for current legal status.
   • Design your PoC to generate production gate evidence, not just technical proof. Know what documentation the regulator will need and build your PoC to produce it.
   • Build regulatory hold states explicitly into your Agile framework. When a regulator pauses your deployment, that is not a project failure. It is a recognised project phase. Treat it as one.

   Multi-country FinTech project management is not harder than other complex work. It is differently hard. The tools and mental models you need are available. They just need to be calibrated to an environment where the most powerful stakeholder is not in your sprint review.