By Anandhan Kannan
The Prerequisite: Before Architecture Comes Agreement
For any financial institution managing clients across borders, this operational tension scenario between central control and local execution is familiar and costly. Group Compliance has just completed the effort to define and ratify a unified global policy, a single standard designed to ensure consistency, control and adherence to international rules, such as Basel Accords and Financial Action Task Force (FATF) recommendations. Simultaneously, Country Office Heads are under pressure to grow revenue, serve clients competitively, and comply with a unique matrix of local regulations that often diverge from the global one. The system they are given must serve both goals: to enforce the global standard without exception, while simultaneously accommodating the local contexts. However, most platforms fail by forcing a choice: either be rigidly global and locally noncompliant, or be endlessly flexible and globally opaque.
This often has its negative consequences: a patchwork of manual workarounds, shadow processes, and regional silos. Onboarding slows to a crawl, taking months for corporate clients. Relationship managers are frustrated, compliance teams are buried in rework, and the bank faces immense regulatory risk as local interpretations diverge from the board-approved global policy. The unaddressed “global vs. local” paradox in Client Lifecycle Management (CLM) can delay revenue, inflate costs, and expose the firm to unacceptable risk.
Through leading large-scale CLM transformations across more than 50 markets, I have found that there exists a third way. It’s not about choosing between strictly global control or local agility. It’s about architecting a system that guarantees the former while enabling the latter. The solution lies in a powerful, yet elegantly simple, architectural paradigm: the 80/20 model.
Part 1: The Core Paradox: Why “Global First” or “Local First” Always Fails
To build an effective solution, we must first diagnose why conventional approaches break under the pressure of global operations. The two most common paths lead to predictably poor outcomes.
The “Global Mandate” Trap: The Illusion of Centralised Control
In this scenario, headquarters, driven by a legitimate need for consistency, dictates a monolithic global platform. All processes are standardised, and locally mandated requirements for a specific Asian market or a uniquely European disclosure requirement become “exceptions.” The exceptions are then managed through fragile mechanisms: manual overrides, offline checklists tucked away in shared drives, or, in the worst case, negotiating with an overloaded IT team for a bespoke code change that may take months to implement. Such a pursuit of uniformity makes a system operationally rigid.
The response at the local level, where teams are unable to serve clients efficiently or comply with local law using the company-wide tool, is to create their own solutions. Excel trackers proliferate; SharePoint lists become the de facto system of record; critical compliance data begins living in email chains. The fundamental flaw here is a misunderstanding of what “standardisation” should mean. It should standardise outcomes (consistent risk decisions, complete audit trails, reliable data) instead of the steps getting there. By forcing identical workflows, the Global Mandate approach standardises the wrong layer of the process, creating friction that local teams are economically and operationally incentivised to bypass.
The “Local Freedom” Trap: The Fragmentation of Scale and Insight
Exhausted by the failures of top-down imposition, some institutions swing to the opposite extreme. They encourage each region or country to build, buy, or maintain whatever system best fits its immediate needs. While this may solve acute local problems, it sows the seeds of long-term dysfunction at the enterprise level. Aggregating group-wide risk exposure can turn into a forensic nightmare. Strategic initiatives stumble upon the unavoidable reality: sharing a Know Your Client (KYC) profile across borders for cross-selling becomes virtually impossible. Data is imprisoned in jurisdictional silos by incompatible systems and data privacy laws.
The cost of maintaining 50 different technologies is staggering, and when global policy changes (e.g. a new sanctions regime, a revised FATF guideline), implementing it requires 50 separate projects. As a result, consistency and efficiency are sacrificed. This approach fragments the very intelligence that makes a global bank valuable: the holistic view of client relationships and group-wide risk. It turns scale from an advantage into a liability, as the cost of change grows linearly (or exponentially) with each new market. The bank loses its ability to act as a unified entity, where each regional branch carries its own technological debt and compliance blind spots.
The Root Cause: Entangled Logic and Technical Debt
The root cause of both failures is the same: business and compliance logic is deeply entangled with user experience and hard-coded into the platform’s core. A rule about collecting a “Certificate of Incorporation” in Singapore is written into the same fabric as the button to upload it. Changing it is a software development task, with requirements gathering, coding, testing, and deployment. This entanglement makes flexibility either impossible (Global Trap) or chaotic (Local Trap). This is the critical technical debt at the heart of most legacy CLM systems. The “what” (the policy requirement) is fused with the “how” (the screen flow) and the “where” (the specific software module). This fusion means that any change, whether driven by a new local law or a global UX improvement, becomes a complex, risky, and slow software development task.
Cost of the Paradox
This fragmentation leads to the direct commercial consequences. Sharing a Know Your Client (KYC) profile across borders for cross-selling becomes impossible: data is locked in jurisdictional silos by different systems and privacy laws. Relationship managers cannot see the clients’ full global footprint, missing obvious revenue opportunities and leaving the bank strategically blind to its own client base.
Part 2: The 80/20 Architecture: Decoupling Policy from Process
The breakthrough has to come from a fundamental architectural shift. What is needed is to shift from developing rigid process flows to prioritise building dynamic policy engines.
The guiding principle is this: Complexity should be moved out of inboxes, hard-coded softwares and manual tools into the adaptable software service. The intelligence behind it, the “why” and “what is needed”, should be dynamic, configurable, and locally aware. This shift in operational philosophy moves compliance from being a procedural checklist enforced on users to an intelligent service provided to them. It frees the analyst from piecing together rules from multiple conflicting manuals by offering a pre-assembled case file with all the required rules in one place. The cognitive load shifts from “What do I need to do?” to “Does this evidence meet the required standard?”
The 80%: The Stable Global Core
Before a single line of code is written, before any architecture is drawn, this crucial first step must be taken: achieving company-wide alignment on a single Global Compliance Policy.
This is the hard, human work that happens in conference rooms across time zones. It involves reconciling interpretations from London, Singapore, or New York to answer one question: “What is our company’s non-negotiable baseline for onboarding and managing a client, anywhere in the world?” This policy certainly relies on the international guidelines but it also has to adapt to the company’s unique attitudes to risks, approved data standards, and internal controls.
Typically, this 80% core includes the following:
- Core Data Model: A “dictionary” defining what a “client,” “beneficial owner,” or “account” is;
- Universal Risk Principles: The foundational methodology for scoring risk levels (e.g., High/Medium/Low) based on factors like industry, geography, and product type;
- Standardised Workflow Stages: The agreed phases (e.g., Pre-Screening → Data Collection → Validation → Risk Assessment → Approval) every client lifecycle goes through;
- Global Control Framework: The mandatory checks applicable everywhere, such as Sanctions screening, Politically Exposed Person (PEP) identification, and core AML validations.
This 80% is built to be solid and unchanging at its core. It ensures every client, in every market, is assessed against the bank’s minimal risk standards. Critically, this core standardises attributes like jurisdiction, entity type, and risk score, which later become the levers that the more adjustable 20% can pull to create infinite, compliant combinations without ever breaking the core model.
The 20%: The Adjustable Local Intelligence
This is where local specifics are, though already not in the manner that used to be chaotic and hardly controllable. The 20% now is a structured, governed layer of configuration that modifies how the global core is applied according to a specific jurisdiction. Crucially, this is handled by compliance analysts and business operations staff, overtaking from the developers.
Think of it as the “rules of the road.” The global core says, “All vehicles must stop at a red signal (Sanctions match).” The local configuration defines what constitutes the “vehicle” (client entity types), the “red signal” (specific local sanctions lists), and the exact procedure for “stopping” (local escalation path). These procedures can be managed through low-code/no-code rule editors or structured configuration tables and often can be fully released in a few hours or days. This velocity of change is what makes the system genuinely responsive to local needs, granting local compliance teams the power to administrate their own regulatory domain.
Part 3: The Mechanism: “Regulation-as-Code” and the Jurisdiction-Specific Addendum Platform
The next question is how to make the 80/20 model operationable? The answer could be found in two concepts that turn policy from passive manuals into active, intelligent systems.
1. Regulation-as-Code: Transforming Manuals into Testable Assets
We systematically deconstruct the ratified policy manual into modular, conditional, executable business rules. Using a business rules engine, we transform policy statements into a precise set of testable rules.
These rules are stored in a centralised repository, separately from the application code. They can be combined, updated, and tested independently. When Singapore’s regulator, the MAS, updates a guideline, a compliance analyst (and not a software developer) updates the relevant rule configuration. One can run simulated client profiles through the rule engine to validate outcomes before deployment. You can “diff” rule sets between versions to produce an exact audit trail of what changed and why. Altogether, this drastically reduces misinterpretation, drift, and operational risk.
2. The Local Compliance Annex tool: Dynamic Local Requirement Assembly
The Local Compliance Annex tool is a real-time, intelligent policy assembler that I developed to improve operational efficiency and user experience. When a Relationship Manager initiates an onboarding case for a corporate client in a specific country, they input the core profile (e.g., Jurisdiction, Entity Type, Industry, Risk Tier).
The tool does not display a static, generic checklist. Instead:
- It queries the Global Policy Engine, applying all mandatory 80% core rules;
- It intelligently layers on every approved rule tagged for that specific jurisdiction (the 20%);
- It generates a tailored, dynamic due diligence checklist – the “Local Compliance Annex.”
The psychological and operational impact is transformative. Instead of facing a 100-field form (where 30 fields can turn out to be irrelevant) the user sees only the 70 fields that are relevant for that specific client in that specific market. This “progressive disclosure” reduces cognitive overload, minimises errors, and accelerates completion. The system starts feeling less like bureaucracy and more like a smart assistant.
The Magic of Concurrent Jurisdiction Logic
For a multinational corporation opening accounts across five countries at once, the tool performs this assembly in parallel for each jurisdiction. The platform can present a consolidated dashboard showing the distinct requirements for the UK Head office entity, the Singapore branch, and the Hong Kong subsidiary all simultaneously. This is what enables core accounts to be activated in days while secondary jurisdictions complete their own parallel checks, something that is unfeasible with monolithic systems. This capability fundamentally changes the economics of serving large global clients, accelerating the onboarding timeline without the constraints from the slowest jurisdiction. Compliance velocity now can go hand in hand with business velocity, transforming the CLM platform into a revenue enabler.
Part 4: The Human Element: Scaling Adoption Through Regional Champions & Command Centres
The most elegant architecture remains a theoretical exercise if the people who must use it daily do not trust or understand it. Successful transformation is powered equally by technology and human behaviour. I view a rollout strategy as deliberate as a software design worked one was engineered with the same rigor as our system architecture. Ignoring this is why many technically sound platforms languish with 30% adoption, forcing the perpetuation of the very shadow systems they were meant to replace.
1. Co-Creation with Regional Champions
Long before development began, we identified and embedded “regional champions” from compliance, operations, and the front office in key markets to become active co-creators. In co-design workshops, they set rules for their jurisdiction and in the so-called ‘sneak-peak sessions’ they further validated UX. This process served a dual purpose: it ensured technical accuracy and built irreplaceable social capital, as the champions could better understand its intricacies and explain the logic to the team-members.
2. The Command Centre & Cross-HIVE Support Model
Go-live is, perhaps, the most critical test. We established region-specific, multi-country Command Centers operating on a HIVE model – a cross-functional team of experts from Technology, Compliance, and Business Operations sitting physically or virtually together. A user with a question about a local document requirement could get an answer in hours instead of 5 days. The technical expert could check the data, the compliance expert could confirm the rule, and the business lead could explain the context, all happening in one interaction.
Part 5: The Tangible Impact: From Paradox to Performance
When the global-local paradox is resolved via applying the 80/20 architecture and a human-centric rollout, the results become transformative and measurable across the key three dimensions.
1. Eradication of Rework and SME Dependency
Before: Regional Subject Matter Experts (SMEs) were bottlenecks, constantly being consulted on what was needed for cross-border requirements. Errors in interpretation led to rework cycles, frustrating clients to continuously present their documents.
After: The platform itself became the SME. The dynamic Local Compliance Annex provided the single, unambigous checklist. We measured a 50% reduction in manual intervention and query cycles during onboarding. More profoundly, it allowed us to codify “tribal knowledge” (a significant operational risk when held undocumented in a few heads) into the system, creating a sustainable model. It freed the experts to focus on higher-value exception management and strategic analysis.
2. Acceleration of Business Velocity and Competitive Advantage
Before: Multi-jurisdiction client onboarding was a sequential relay race, often taking 45-90 days, with the revenue delayed at every handoff.
After: With concurrent jurisdiction processing and pre-validated requirements, core accounts could be activated in days, not months, while other jurisdictions finalised in their own timeline. We documented 30-70% faster client activation times, directly unlocking earlier revenue realisation. In a landscape where client experience is paramount, a swift, smooth, and predictable onboarding process becomes a key competitive differentiator. Relationship Managers gain a powerful tool to attract and retain large corporate clients. The CLM platform shifts from being perceived as a pure cost and constraint to a tangible contributor to growth and client satisfaction, fundamentally altering its value proposition to the entire institution.
The Essential Shift: From Operational to Product Mindset
Ultimately, the global-local paradox in compliance is a design challenge. The 80/20 architecture provides the technical blueprint, but its success requires a fundamental cultural shift: from an Operational Mindset to a Product Mindset.
The Operational Mindset sees compliance as a cost center: a series of tasks and IT projects focused on outputs. It leads to the rigid systems and shadow processes that define today’s failures. The Product Mindset redefines compliance as a strategic capability and shifts the focus to outcomes: accelerating revenue, demonstrably reducing risk, and empowering users. It treats the CLM platform as a living product, owned by cross-functional teams who iterate based on user feedback and changing regulations.
This mindset is what makes the 80/20 model work. The stable 80% core embodies global control – and the adjustable 20% layer empowers local agility. Together, they form a system that is inherently adaptable and can be continuously refined.
The future of competitive finance belongs to institutions that master this shift. They will not see compliance as a constraint to be managed, but as a core product to be engineered for excellence. By investing in a product-led approach, they will finally resolve the paralysing tension between global company-wide standards and local execution, transforming compliance into a source of business speed, trust, and growth.
