Technology Platform Selection - Build vs. Buy vs. Partner

BUILD CUSTOM - COMPLETE ANALYSIS

WHAT IT MEANS:
├── Central bank develops platform internally
├── May use open-source foundations
├── Complete control over design and implementation
├── Full intellectual property ownership
└── Self-maintained and operated

REQUIRED CAPABILITIES:
├── 20-50+ engineers and architects
├── Security specialists
├── Cryptography expertise
├── Payment systems knowledge
├── Project management capacity
├── Ongoing maintenance organization
└── Multi-year commitment

COST ESTIMATE:
├── Development: $50-200M+ over 3-5 years
├── Annual operations: $10-30M
├── Total 10-year cost: $150-500M
└── Often exceeds estimates by 50-100%

TIMELINE:
├── Design and architecture: 12-18 months
├── Core development: 18-24 months
├── Testing and pilots: 12-18 months
├── Production deployment: 6-12 months
├── Total: 4-6 years minimum
└── Typically 5-7 years in practice

ADVANTAGES:
✅ Complete sovereignty and control
✅ No vendor dependency
✅ Exact requirements match
✅ Full IP ownership
✅ No licensing costs
✅ Maximum flexibility for modifications
✅ No vendor business risk

DISADVANTAGES:
❌ Very expensive
❌ Long timeline
❌ Requires deep expertise (rare in central banks)
❌ Risk of reinventing solved problems
❌ Maintenance burden indefinitely
❌ May fall behind commercial innovation
❌ Single point of expertise failure (staff turnover)

BEST FOR:
├── Large economies with resources (China, India, EU)
├── Strong internal technology capability
├── Unique requirements not met by vendors
├── Maximum sovereignty priority
└── Multi-decade operational commitment

EXAMPLES:
├── China e-CNY: Custom platform
├── ECB Digital Euro: Custom (with vendor components)
├── India e-rupee: Custom (building on existing systems)
└── Large economies generally
```

BUY COMMERCIAL - COMPLETE ANALYSIS

WHAT IT MEANS:
├── Acquire/license existing platform
├── Vendor provides core technology
├── Configuration rather than development
├── Vendor support and maintenance
└── Ongoing licensing relationship

VENDOR TYPES:
├── Specialized CBDC platforms (Ripple, Bitt, G+D)
├── Enterprise blockchain (R3, ConsenSys, IBM)
├── Financial technology vendors (Temenos, FIS)
└── System integrators with platforms (Accenture, Deloitte)

COST ESTIMATE:
├── Initial licensing: $5-50M
├── Implementation: $10-30M
├── Annual licensing: $2-10M
├── Annual support: $2-5M
├── Total 10-year cost: $50-150M
└── More predictable than build

TIMELINE:
├── Vendor selection: 6-12 months
├── Configuration and integration: 12-18 months
├── Testing and pilots: 6-12 months
├── Production: 3-6 months
├── Total: 2-4 years
└── Significantly faster than build

ADVANTAGES:
✅ Faster time to market
✅ Proven technology
✅ Vendor expertise and support
✅ Lower upfront cost
✅ Known solution with references
✅ Reduced technical risk
✅ Benefit from vendor's other implementations

DISADVANTAGES:
❌ Vendor dependency
❌ Sovereignty concerns (foreign vendor)
❌ Customization limits
❌ Long-term license costs
❌ Vendor business risk (bankruptcy, acquisition, pivot)
❌ May not meet unique requirements
❌ Data and operational dependencies

BEST FOR:
├── Smaller economies with limited resources
├── Faster deployment priority
├── Standard requirements
├── Limited internal technology capacity
└── Acceptable vendor dependency

EXAMPLES:
├── Bahamas Sand Dollar: NZIA (now Metaco/Ripple)
├── Nigeria eNaira: Bitt Inc.
├── Jamaica Jam-Dex: eCurrency Mint
└── Many smaller economy pilots
```

PARTNERSHIP MODEL - COMPLETE ANALYSIS

WHAT IT MEANS:
├── Central bank + vendor collaboration
├── Shared development responsibility
├── Knowledge transfer component
├── Joint intellectual property (potentially)
└── Long-term relationship, not transaction

PARTNERSHIP TYPES:

Technology Partnership:
├── Vendor provides platform foundation
├── Central bank customizes and extends
├── Knowledge transfer over time
├── Potential IP sharing
└── Example: Some European pilots

Development Partnership:
├── Joint development team
├── Central bank staff work with vendor
├── Shared roadmap decisions
├── Mutual learning
└── Example: Some BIS innovation hub projects

Strategic Partnership:
├── Multi-year commitment
├── Exclusive or preferred relationship
├── Joint go-to-market for other markets
├── Shared commercial benefits
└── Example: Some vendor-central bank relationships

COST ESTIMATE:
├── Initial: $20-80M
├── Ongoing: $5-15M annually
├── Knowledge transfer value: Significant
├── Total 10-year cost: $70-200M
└── Between build and buy

TIMELINE:
├── Partnership negotiation: 6-12 months
├── Joint development: 18-24 months
├── Testing and pilots: 6-12 months
├── Production: 3-6 months
├── Total: 3-4 years
└── Between build and buy

ADVANTAGES:
✅ Leverage vendor expertise
✅ Build internal capability over time
✅ Shared risk
✅ Flexibility in relationship
✅ Knowledge transfer
✅ Potential IP rights
✅ Alignment of interests

DISADVANTAGES:
❌ Complex governance
❌ Negotiation overhead
❌ Shared decision-making friction
❌ Partner alignment can drift
❌ Accountability ambiguity
❌ Exit complexity
❌ Contract management burden

BEST FOR:
├── Medium-sized economies
├── Desire for capability building
├── Balanced sovereignty and practicality
├── Willingness to invest in relationship
└── Long-term strategic view

---

CBDC VENDOR LANDSCAPE (2025)

SPECIALIZED CBDC VENDORS:

RIPPLE (CBDC Platform)
├── Technology: Private XRPL derivative
├── Approach: White-label, full-stack
├── Announced projects: Palau, Bhutan, Montenegro, Georgia
├── Strengths:
│ ├── Cross-border expertise
│ ├── Turnkey solution
│ └── Established company
├── Concerns:
│ ├── XRP association (political)
│ ├── Small pilot countries only
│ └── No major central bank adoption
├── Pricing: Not publicly disclosed
└── Assessment: Real product, but unproven at scale

BITT INC.
├── Technology: Custom blockchain platform
├── Approach: Full implementation partner
├── Projects: Nigeria eNaira, Eastern Caribbean DCash
├── Strengths:
│ ├── Multiple implementations
│ ├── Retail CBDC focus
│ └── Caribbean experience
├── Concerns:
│ ├── Project struggles (eNaira, DCash)
│ ├── Smaller company
│ └── Limited reference success
├── Pricing: Project-based
└── Assessment: Experience but poor track record

G+D (GIESECKE+DEVRIENT)
├── Technology: Filia platform
├── Approach: Security-focused, modular
├── Projects: Multiple pilots globally
├── Strengths:
│ ├── Strong security heritage
│ ├── Physical + digital currency expertise
│ └── European headquarters
├── Concerns:
│ ├── Less public information
│ └── Primarily hardware history
├── Pricing: Not publicly disclosed
└── Assessment: Credible, especially for security-conscious

SORAMITSU
├── Technology: Hyperledger Iroha (open-source)
├── Approach: Open-source with services
├── Projects: Cambodia Bakong
├── Strengths:
│ ├── Open-source (no lock-in)
│ ├── Proven deployment (Cambodia)
│ └── Japanese backing
├── Concerns:
│ ├── Smaller ecosystem
│ └── Limited marketing presence
├── Pricing: Implementation services
└── Assessment: Underrated, proven in production

ENTERPRISE BLOCKCHAIN PLATFORMS:

R3 (CORDA)
├── Technology: Corda Enterprise
├── Approach: Enterprise blockchain platform
├── Projects: Multiple wholesale pilots
├── Strengths:
│ ├── Major bank backing
│ ├── Enterprise credibility
│ └── Wholesale focus
├── Concerns:
│ ├── Complexity
│ ├── Less retail CBDC focus
│ └── Consortium governance questions
├── Pricing: Enterprise licensing
└── Assessment: Strong for wholesale, complex for retail

CONSENSYS (ETHEREUM)
├── Technology: Enterprise Ethereum
├── Approach: Ethereum-based solutions
├── Projects: Hong Kong, Singapore experiments
├── Strengths:
│ ├── Ethereum ecosystem
│ ├── Developer tools
│ └── Innovation culture
├── Concerns:
│ ├── Ethereum association
│ ├── Gas/complexity perception
│ └── Enterprise vs. public chain tension
├── Pricing: Project-based
└── Assessment: Innovative but niche

SYSTEM INTEGRATORS:

IBM
├── Technology: Hyperledger Fabric (historical)
├── Approach: Consulting + platform
├── Projects: Various experiments
├── Strengths:
│ ├── Enterprise credibility
│ ├── Global presence
│ └── Integration expertise
├── Concerns:
│ ├── Pivot away from blockchain
│ ├── Expensive
│ └── Technology commitment questions
├── Pricing: Consulting rates
└── Assessment: Declining blockchain focus

ACCENTURE/DELOITTE/EY
├── Technology: Platform-agnostic
├── Approach: Implementation services
├── Strengths:
│ ├── Implementation expertise
│ ├── Central bank relationships
│ └── Risk management
├── Concerns:
│ ├── Not technology owners
│ ├── Very expensive
│ └── Quality varies by team
├── Pricing: High consulting rates
└── Assessment: Useful for implementation, not platform
```

Given Ripple's prominence in the XRP community, a detailed assessment is warranted:

RIPPLE CBDC PLATFORM - DETAILED ANALYSIS

WHAT IT IS:
├── White-label CBDC platform
├── Based on private XRPL technology
├── NOT the public XRP Ledger
├── Does NOT require XRP token
└── Customizable for central bank requirements

TECHNOLOGY STACK:
├── Core: Private ledger (XRPL derivative)
├── Consensus: Configurable (not public XRPL consensus)
├── Smart contracts: Hooks capability
├── Privacy: Central bank controlled
├── Interoperability: Optional XRPL bridge
└── Scalability: Claims enterprise-grade

ANNOUNCED ENGAGEMENTS:

Palau (2021-present):
├── Status: Limited launch (Palau Stablecoin)
├── Scope: Digital residency + stablecoin
├── Scale: Very small (Palau pop: ~18,000)
└── Reality: Pilot, not full CBDC

Bhutan (2022-present):
├── Status: Pilot exploration
├── Scope: Retail + wholesale concepts
├── Scale: Small (Bhutan pop: ~780,000)
└── Reality: Early stage, limited information

Montenegro (2022-present):
├── Status: Pilot announced
├── Scope: Digital currency exploration
├── Scale: Small (pop: ~620,000)
└── Reality: Early stage

Georgia (2023-present):
├── Status: Partnership announced
├── Scope: Digital currency exploration
├── Scale: Small (pop: ~3.7M)
└── Reality: Very early stage

Colombia (announced):
├── Status: Engagement announced
├── Scope: Land registry (NOT CBDC)
└── Reality: Mischaracterized as CBDC

HONEST ASSESSMENT:

Strengths:
✅ Real platform with real deployments
✅ Established company with resources
✅ Cross-border/interoperability expertise
✅ Turnkey solution reduces complexity

Weaknesses:
❌ All pilots in small economies
❌ No major central bank adoption
❌ XRP association creates political concerns
❌ Limited public information on performance
❌ Competitive claims often not verifiable

XRP IMPLICATIONS:
├── Platform success ≠ XRP success
├── Private ledger doesn't use XRP
├── Interoperability COULD use XRP (optional)
├── No announced XRP integration in CBDC pilots
└── Investment implication: Platform is real, XRP link is speculative

PROBABILITY ASSESSMENT:
├── Ripple platform gains more pilots: 70%
├── Ripple wins major central bank: 15-25%
├── XRP becomes integral to Ripple CBDC: 5-10%
└── Do not overweight this as XRP catalyst
```

OPEN SOURCE CBDC OPTIONS

HYPERLEDGER FABRIC
├── Origin: Linux Foundation / IBM
├── Type: Permissioned blockchain
├── CBDC use: Multiple experiments
├── Strengths: Modularity, enterprise features
├── Concerns: Complexity, IBM dependency history
└── Cost: Free (implementation costs apply)

HYPERLEDGER BESU
├── Origin: Linux Foundation / ConsenSys
├── Type: Ethereum client
├── CBDC use: Some experiments
├── Strengths: Ethereum compatibility
├── Concerns: Ethereum complexity
└── Cost: Free (implementation costs apply)

HYPERLEDGER IROHA
├── Origin: Linux Foundation / Soramitsu
├── Type: Simple DLT for digital assets
├── CBDC use: Cambodia Bakong (production)
├── Strengths: Simplicity, proven deployment
├── Concerns: Smaller ecosystem
└── Cost: Free (implementation costs apply)

CORDA OPEN SOURCE
├── Origin: R3
├── Type: Enterprise DLT
├── CBDC use: Multiple wholesale experiments
├── Strengths: Enterprise design, privacy
├── Concerns: R3 business model changes
└── Cost: Free (enterprise features paid)

OPEN SOURCE ASSESSMENT:

Advantages:
✅ No licensing fees
✅ No vendor lock-in
✅ Transparency (auditable code)
✅ Community support
✅ Modification freedom
✅ Long-term availability

Disadvantages:
❌ Requires internal expertise
❌ No vendor support (or paid separately)
❌ Integration and customization burden
❌ May lack CBDC-specific features
❌ Quality varies by project
❌ Community may shift focus

BEST FOR:
├── Central banks with strong technical teams
├── Sovereignty priority
├── Budget constraints on licensing
├── Willingness to invest in customization
└── Long-term self-sufficiency goal

---

DLT VS. CENTRALIZED - FUNDAMENTAL QUESTION

THE QUESTION:
Does CBDC need distributed ledger technology,
or can a centralized database serve the purpose?

THE DEBATE:

PRO-DLT ARGUMENTS:
├── Resilience (no single point of failure)
├── Transparency (shared ledger)
├── Programmability (smart contracts)
├── Interoperability (cross-chain potential)
├── Innovation (leverages blockchain advances)
└── Future-proofing (tokenization ecosystem)

PRO-CENTRALIZED ARGUMENTS:
├── Performance (millions of TPS possible)
├── Simplicity (proven technology)
├── Cost (no consensus overhead)
├── Control (central bank decides everything anyway)
├── "Blockchain theater" (DLT for its own sake)
└── Precedent (existing payment systems work)

THE HONEST ASSESSMENT:

For RETAIL CBDC:
├── High transaction volumes favor centralized
├── Single issuer (central bank) anyway
├── Privacy easier without shared ledger
├── Performance more critical
└── DLT overhead may be unnecessary

For WHOLESALE CBDC:
├── Multiple participants benefit from shared ledger
├── Smart contracts for DvP settlement
├── Interoperability with tokenized assets
├── Lower transaction volume (DLT can handle)
└── DLT advantages more relevant

EMERGING CONSENSUS:
├── Retail: Centralized or simple DLT often sufficient
├── Wholesale: DLT benefits more apparent
├── Hybrid: Mix based on specific requirements
└── Technology choice should follow requirements, not trends
```

PERFORMANCE COMPARISON

CENTRALIZED DATABASE:
├── Throughput: Millions of TPS possible
├── Latency: Milliseconds
├── Proven at scale: Visa, card networks
├── Technology: Mature, well-understood
└── Example: Traditional payment systems

DISTRIBUTED LEDGER:
├── Throughput: Hundreds to thousands TPS (varies)
├── Latency: Seconds (consensus time)
├── Proven at scale: Bitcoin, Ethereum (different use case)
├── Technology: Evolving, improving
└── Example: Various CBDC pilots

REALITY CHECK:

Current CBDC transaction volumes:
├── e-CNY peak: ~100K TPS claimed capacity
├── Actual usage: Far below capacity
├── Retail CBDC: Thousands TPS typically sufficient now
└── Growth capacity needed for success scenario

The performance argument:
├── Is often theoretical (current volumes are low)
├── May matter for scale scenarios
├── DLT is improving rapidly
├── Centralized can always be added alongside
└── Don't over-engineer for hypothetical scale

RECOMMENDATION:
Design for 10x expected peak
Most DLT platforms can handle current CBDC volumes
Performance rarely the actual constraint
```

BLOCKCHAIN THEATER ANALYSIS

DEFINITION:
Using distributed ledger technology when centralized
would work equally well, primarily for:
├── Innovation signaling
├── Marketing value
├── Vendor influence
└── Following trends

WARNING SIGNS:
├── "We need blockchain for CBDC"
├── No articulated DLT benefit
├── Vendor pushing DLT for its own sake
├── DLT-first rather than requirements-first
└── Inability to explain why DLT vs. centralized

VALID DLT REASONS:
├── Multi-party ecosystem (wholesale)
├── Smart contract requirements
├── Interoperability with tokenized assets
├── Specific resilience requirements
├── Audit/transparency features
└── Programmable money features

INVALID DLT REASONS:
├── "Blockchain is the future"
├── Vendor recommends it
├── Other countries are using it
├── Sounds more innovative
├── Don't want to be "behind"
└── Haven't evaluated alternatives

---

CBDC PLATFORM SELECTION CRITERIA

CATEGORY 1: TECHNICAL CAPABILITIES (25%)

□ Functional completeness
├── Core CBDC features (issuance, transfer, redemption)
├── Wallet management
├── Offline capability (if required)
├── Programmability (if required)
└── Interoperability features

□ Performance
├── Transaction throughput
├── Latency
├── Scalability path
└── Demonstrated at scale

□ Security
├── Cryptographic foundations
├── Security audit history
├── Vulnerability management
└── Key management

□ Integration capability
├── API quality
├── Standard compatibility
├── Legacy system integration
└── Third-party ecosystem

CATEGORY 2: VENDOR VIABILITY (25%)

□ Company stability
├── Financial health
├── Ownership structure
├── Business model sustainability
└── Acquisition risk

□ Track record
├── CBDC deployments
├── Reference customers
├── Project success rate
└── Implementation experience

□ Support capability
├── Implementation services
├── Ongoing support model
├── Geographic presence
└── Language capabilities

□ Innovation trajectory
├── R&D investment
├── Roadmap clarity
├── Technology currency
└── Community/ecosystem

CATEGORY 3: STRATEGIC FIT (25%)

□ Sovereignty alignment
├── Data residency options
├── Independence from vendor
├── Exit strategy viability
└── IP rights

□ Regulatory compatibility
├── Compliance features
├── Privacy capabilities
├── Audit requirements
└── Jurisdictional experience

□ Long-term relationship
├── Contract flexibility
├── Partnership potential
├── Knowledge transfer
└── Exit provisions

CATEGORY 4: COMMERCIAL TERMS (25%)

□ Cost structure
├── Upfront costs
├── Ongoing licensing
├── Support costs
├── Implementation costs
└── Total cost of ownership (10 year)

□ Contract terms
├── Term length
├── Termination rights
├── IP provisions
├── Liability allocation
└── Change management

□ Payment structure
├── Fixed vs. variable
├── Payment schedule
├── Performance incentives
└── Price protection
```

RECOMMENDED SELECTION PROCESS

PHASE 1: REQUIREMENTS DEFINITION (2-3 months)
├── Document functional requirements
├── Document non-functional requirements
├── Define evaluation criteria and weights
├── Establish budget parameters
└── Gain stakeholder alignment on requirements

PHASE 2: MARKET SURVEY (1-2 months)
├── Identify potential vendors
├── Request information (RFI)
├── Create long list
├── Preliminary capability mapping
└── Narrow to short list (3-5 vendors)

PHASE 3: DETAILED EVALUATION (3-4 months)
├── Issue request for proposal (RFP)
├── Conduct vendor presentations
├── Technical deep dives
├── Reference checks
├── Proof of concept (if warranted)
└── Score against criteria

PHASE 4: NEGOTIATION (2-3 months)
├── Select preferred vendor(s)
├── Negotiate commercial terms
├── Finalize contract
├── Establish governance
└── Plan implementation

PHASE 5: DECISION (1 month)
├── Final recommendation
├── Governance approval
├── Contract execution
└── Implementation kickoff

TOTAL TIMELINE: 9-13 months
Don't shortcut—poor selection creates years of problems
```

RISK COMPARISON BY APPROACH

BUILD CUSTOM RISKS:
├── Delivery risk: HIGH
│ └── Custom development often fails or overruns
├── Expertise risk: HIGH
│ └── Key person dependencies, turnover
├── Maintenance risk: MEDIUM-HIGH
│ └── Long-term capability required
├── Vendor risk: LOW
│ └── No vendor dependency
├── Sovereignty risk: LOW
│ └── Full control
├── Cost risk: HIGH
│ └── Overruns common (50-100%)
└── Timeline risk: HIGH
└── Delays common (12-24 months)

BUY COMMERCIAL RISKS:
├── Delivery risk: MEDIUM
│ └── Proven product, but integration challenges
├── Vendor risk: HIGH
│ └── Dependency on vendor viability, decisions
├── Sovereignty risk: MEDIUM-HIGH
│ └── Foreign vendor, data concerns
├── Customization risk: MEDIUM
│ └── Limits on modifications
├── Lock-in risk: HIGH
│ └── Difficult to switch vendors
├── Cost risk: MEDIUM
│ └── More predictable, but license increases
└── Timeline risk: MEDIUM
└── Faster, but still integration challenges

PARTNERSHIP RISKS:
├── Governance risk: HIGH
│ └── Complex decision-making, alignment drift
├── Delivery risk: MEDIUM
│ └── Shared responsibility can mean unclear accountability
├── Relationship risk: MEDIUM-HIGH
│ └── Partnership can sour, exit is complex
├── IP risk: MEDIUM
│ └── Ownership questions, future use
├── Cost risk: MEDIUM
│ └── Partnership overhead, negotiation costs
└── Timeline risk: MEDIUM
└── Partnership setup takes time

MITIGATION STRATEGIES:

For build:
├── Hire experienced leadership early
├── Use external architecture review
├── Build in contingency (time and budget)
└── Have fallback plan

For buy:
├── Strong contract protections
├── Escrow arrangements for source code
├── Exit clause planning
└── Ongoing relationship management

For partnership:
├── Clear governance structure
├── Defined decision rights
├── Exit provisions
└── Regular relationship health checks

---

✅ All approaches can work: Build (China), Buy (Bahamas, Nigeria), and Partnership models have all delivered functioning CBDC platforms. Technology failure is rarely the cause of CBDC failure.

✅ Build takes longer and costs more: Custom development consistently takes 4-6+ years and often exceeds budget by 50-100%. This is well-documented across government technology projects.

✅ Vendor landscape is immature: No CBDC vendor has an unambiguous success story. All have limited deployments, and projects using their platforms have struggled with adoption (not technology).

✅ DLT isn't always necessary: Centralized architectures can meet many CBDC requirements. The choice should follow requirements, not technology trends.

⚠️ Which vendors will survive: The CBDC vendor market is immature and consolidating. Some current vendors may not exist in 10 years.

⚠️ Whether Ripple will win major central banks: Ripple has a real platform but only small-country pilots. Major central bank adoption remains uncertain.

⚠️ Whether open source can match commercial: Open-source options require more internal expertise but offer sovereignty advantages. The trade-off is context-dependent.

🔴 Selecting vendor before defining requirements: This leads to capability-driven rather than needs-driven implementations.

🔴 Underestimating vendor risk: Small vendors can fail, pivot, or be acquired. Contract protections and exit planning are essential.

🔴 "Blockchain theater": Using DLT for innovation signaling rather than genuine requirements wastes resources and adds complexity.

🔴 Shortcutting selection process: Poor vendor selection creates years of problems. Invest the 9-12 months required.

Technology platform selection is important but often overemphasized. CBDCs fail because of adoption challenges, not technology failures. All major approaches (build, buy, partner) can deliver working platforms. The choice should reflect resource constraints, sovereignty priorities, and timeline requirements—not technology enthusiasm. Most importantly, no platform choice can overcome poor stakeholder management or absent value proposition.

---

Assignment: Create a technology vendor evaluation scorecard and apply it to assess three CBDC vendors for a hypothetical central bank.

Requirements:

Part 1: Evaluation Framework (2 pages)

• Categories (Technical, Vendor Viability, Strategic Fit, Commercial)
• Specific criteria within each category (minimum 5 per category)
• Scoring scale (recommend 1-5 or 1-10)
• Weights for each category and criterion
• Total weighted score calculation methodology

Part 2: Central Bank Profile (1 page)

• Country size and economy
• Technical capacity
• Budget constraints
• Timeline requirements
• Specific CBDC objectives
• Sovereignty priorities

Part 3: Vendor Evaluations (3-4 pages)

• Ripple CBDC Platform

• R3 Corda

• Hyperledger (Iroha or Fabric)

• Bitt Inc.

• G+D Filia

• Score against each criterion

• Provide brief rationale for scores

• Calculate total weighted score

• Identify key strengths and concerns

Part 4: Recommendation (1 page)

• Rank vendors by total score

• Recommend preferred vendor (or build approach)

• Identify key risks with recommendation

• Describe mitigation strategies

• Note any information gaps requiring further investigation

• Framework completeness and logic (25%)

• Central bank profile relevance (15%)

• Vendor evaluation rigor and evidence (35%)

• Recommendation quality and defensibility (25%)

Time investment: 3-4 hours
Value: Creates reusable evaluation framework applicable to actual vendor selections.

---

For Next Lesson:
Lesson 6 examines legal and regulatory framework development—often the longest lead-time item in CBDC implementation. We'll cover the legal foundations required before launch and why rushing this step guarantees problems.

---

End of Lesson 5

Total words: ~5,800
Estimated completion time: 60 minutes reading + 3-4 hours for deliverable