How Central Banks Actually Choose Technology Partners

When a private company chooses enterprise software, the process is relatively straightforward: evaluate options, select the best fit for requirements and budget, negotiate a contract, implement. The decision-makers are executives accountable to shareholders, and speed matters.

Central bank technology decisions operate under entirely different rules.

The Core Difference:

• Primary goal: Business value and efficiency

• Decision-makers: Executives and IT leadership

• Accountability: Shareholders and board

• Timeline: Months

• Risk tolerance: Moderate (can recover from mistakes)

• Political considerations: Minimal

• Primary goal: Monetary system stability and sovereignty

• Decision-makers: Multiple stakeholders with veto power

• Accountability: Government, public, international community

• Timeline: Years

• Risk tolerance: Near-zero (mistakes affect entire economy)

• Political considerations: Dominant

A private company can adopt new technology, discover problems, and course-correct. A central bank deploying flawed CBDC infrastructure could undermine public confidence in the national currency—a catastrophic outcome with no easy recovery.

This fundamental difference shapes everything about how central banks approach technology partnerships.

Central bank technology decisions involve at least five distinct stakeholder groups, each with different priorities and effective veto power:

Stakeholder 1: Central Bank Technical Teams

These are the engineers, architects, and IT professionals within the central bank itself. Their concerns are primarily technical:

• Can we operate this technology long-term?
• Do we have or can we develop the internal expertise?
• Is the architecture sound and secure?
• What happens if the vendor disappears?
• Can we audit and modify the code?

Technical teams often prefer open-source solutions or building in-house because these approaches maximize their control and minimize dependency. They're typically skeptical of vendor marketing claims and want to see proof of concepts before making recommendations.

Stakeholder 2: Central Bank Leadership

The governor, deputy governors, and board members of the central bank have different concerns than their technical teams:

• Will this embarrass us if it fails?
• What's the reputational risk of partnering with this vendor?
• How will other central banks perceive this decision?
• Does this align with our institutional mandate?
• What are the political implications?

Central bank leaders are often cautious to the point of paralysis. Their careers can be destroyed by a single high-profile failure, but success rarely generates proportional rewards. This asymmetric risk profile creates a strong bias toward inaction or choosing the most conservative option.

Stakeholder 3: Government and Treasury

In most countries, central banks are operationally independent but ultimately accountable to the government. Finance ministries and treasury departments influence major technology decisions:

• Does this align with government policy?
• What are the fiscal implications?
• How does this affect government payment systems?
• Are there geopolitical considerations?
• What do our allies and trading partners think?

Government stakeholders often have priorities orthogonal to technical merit. A technically superior solution from a geopolitically problematic vendor may be rejected purely on political grounds.

Stakeholder 4: Commercial Banks

CBDCs directly affect commercial banks—potentially disintermediating them from retail payments. Commercial banks are both potential partners and potential opponents:

• Does this threaten our retail banking business?
• How does CBDC integration work with our systems?
• What role do we play in distribution?
• Are our concerns being heard in the design process?

In many countries, commercial bank lobbying has significantly slowed CBDC development. They can influence central bank decisions through industry associations, direct relationships, and political pressure.

Stakeholder 5: External Advisors and Consultants

Major central bank technology decisions almost always involve outside advisors—management consultancies, specialized fintech advisors, law firms:

• What's the defensible recommendation?
• Have we done adequate due diligence?
• What are the risks we need to document?
• How does this compare to what peers are doing?

Advisors add a layer of process that extends timelines but provides political cover. A central bank governor who chooses a vendor endorsed by McKinsey or Accenture has defensibility if things go wrong. One who makes an unconventional choice bears personal risk.

Here's what makes central bank decisions uniquely challenging: each stakeholder group effectively has veto power.

How Decisions Actually Get Made:

SCENARIO: Central Bank X Evaluating CBDC Platform

Technical Team: "Vendor A has better architecture"
Leadership: "Vendor A has a regulatory problem in the US"
Government: "Vendor B is from an allied nation"
Commercial Banks: "We prefer Vendor C's integration approach"
Advisors: "All three have risks we need to document"

1. No decision (most common) - project delayed indefinitely
2. Build in-house - avoids vendor selection conflict
3. Multi-vendor pilot - kicks the can down the road
4. Compromise choice - nobody's first preference but acceptable to all

This dynamic explains why CBDC development moves so slowly even when all stakeholders theoretically support the concept. Any stakeholder can delay or derail the process by raising concerns.

It also explains why vendor "partnership" announcements rarely translate to production. Getting a pilot approved (which requires only modest consensus) is far easier than getting production deployment approved (which requires full stakeholder alignment).

---

If you asked most technology vendors what central banks want, they'd emphasize features: scalability, programmability, interoperability, transaction speed. While these matter, they're not what central banks prioritize most.

Based on analysis of CBDC procurement processes and central bank publications, here's the actual priority stack:

Priority 1: Sovereignty and Control (Non-negotiable)

Above all else, central banks require absolute control over their monetary infrastructure. This manifests in several ways:

SOVEREIGNTY REQUIREMENTS:

- Must be able to operate without vendor involvement
- Transition plan required before deployment
- Training and knowledge transfer mandatory

- Source code access (audit rights at minimum)
- Ability to modify without permission (preferred)
- No "black box" components

- All transaction data under central bank jurisdiction
- No data sharing with vendor or third parties
- Geographic data location requirements

- All policy decisions remain with central bank
- Vendor cannot unilaterally change functionality
- Updates require central bank approval

Any vendor that can't meet sovereignty requirements won't get past initial screening, regardless of technical superiority.

Priority 2: Security and Reliability (Zero Tolerance)

Central banks operate critical national infrastructure. Their risk tolerance for security failures is essentially zero.

SECURITY REQUIREMENTS:

- Proven production deployments
- Independent security audits
- Responsiveness to vulnerabilities

- Defense in depth
- No single points of failure
- Air-gapped operations possible

- Disaster recovery capabilities
- Business continuity planning
- Tested failover procedures

RELIABILITY REQUIREMENTS:

• 99.999% uptime expectations (5 nines)
• Degraded operation modes defined
• Recovery time objectives measured in minutes

Here's where blockchain vendors often struggle: traditional financial infrastructure providers (Fidelity National Information Services, Finastra, Temenos) have decades of operational history running mission-critical banking systems. Blockchain vendors have years at most, and few production deployments at scale.

Priority 3: Regulatory Compliance

CBDC systems must comply with existing legal frameworks, which vary by jurisdiction:

• Anti-money laundering (AML) requirements
• Know-your-customer (KYC) integration
• Privacy regulations (GDPR in Europe, various elsewhere)
• Accessibility requirements
• Consumer protection laws

Vendors must demonstrate not just that their technology can meet these requirements, but that they understand the regulatory landscape and can adapt as regulations evolve.

Priority 4: Political Acceptability

This is where the evaluation gets complicated for crypto-adjacent vendors:

POLITICAL CONSIDERATIONS:

- Any controversies or legal issues?
- Regulatory standing in major markets?
- Association with problematic actors?

- Vendor's home country relationship
- Sanctions exposure
- CFIUS concerns (for US-adjacent)

- Does this align with government messaging?
- Will opposition attack this choice?
- Public perception of vendor/technology

- SEC lawsuit (2020-2024) created reputational overhang
- XRP association triggers "crypto skepticism"
- Some jurisdictions avoid US vendors post-SWIFT weaponization
- Conservative politicians conflate CBDC with "surveillance"

A technically excellent vendor with political baggage often loses to an adequate vendor with clean positioning.

Priority 5: Technical Capability (Yes, Finally)

Only after the above considerations are satisfied do central banks focus on technical merit:

• Scalability to national payment volumes
• Transaction throughput and latency
• Smart contract / programmability capabilities
• Interoperability with existing systems
• Offline payment capability
• Future upgrade path

Importantly, central banks are often satisfied with "good enough" technical capability rather than "best in class." A proven system that meets requirements beats a theoretically superior system with less production history.

Priority 6: Cost

Cost matters, but less than vendors might expect. Central banks have substantial budgets for critical infrastructure. Total cost of ownership over 10-20 years matters more than initial implementation cost.

Given these priorities, it becomes clear why most G20 central banks prefer internal development:

The Build Decision Logic:

FOR IN-HOUSE DEVELOPMENT:

- Full code ownership
- No vendor dependency
- Complete control

- No external attack surface via vendor
- Internal team fully vetted
- No supply chain risk

- No vendor controversies
- No geopolitical complications
- "Built by the central bank" messaging

- No licensing fees
- No ongoing vendor payments
- Staff become permanent experts

China's digital yuan (e-CNY) was built entirely in-house. The European Central Bank's digital euro project relies primarily on internal development with consulting support. The Federal Reserve's research is conducted internally with academic collaboration.

The pattern is consistent: the more important the economy, the more likely internal development.

When Vendors Win:

Vendors primarily win in scenarios where internal development isn't feasible:

VENDOR OPPORTUNITY CONDITIONS:

- Limited internal technical capability
- Can't justify full development team
- Examples: Palau, Bhutan, Montenegro

- Political pressure for quick results
- Internal development too slow
- Pilot needed for credibility

- Cross-border focus (Ripple's positioning)
- Particular technical requirement
- Advisory-led vendor selection

This explains Ripple's partnership pattern: primarily small economies that lack resources for internal development and are more willing to work with private vendors.

---

When companies announce central bank "partnerships," they're using a term that covers vastly different levels of commitment. Understanding this spectrum is essential for evaluating announcements.

Level 1: Memorandum of Understanding (MoU)

• Non-binding agreement to explore collaboration

• Often signed at conferences or state visits

• No money typically changes hands

• No commitment to proceed

• Central bank is willing to talk

• May lead to something or may not

• Often just relationship-building

• PR value for both parties

SUCCESS RATE TO PRODUCTION: <5%

EXAMPLE LANGUAGE:
"X and Y signed an MoU to explore potential collaboration
on digital currency innovation..."

MoUs are essentially formalized business card exchanges. They indicate interest, not commitment. Many MoUs never progress beyond the signing ceremony.

Level 2: Research/Study Agreement

• Vendor provides research support

• May involve paid consulting

• Central bank evaluates technology

• Still exploratory, not committal

• More substantive than MoU

• Real work is happening

• But no deployment decision made

• Vendor is being evaluated, not chosen

SUCCESS RATE TO PRODUCTION: ~10%

EXAMPLE LANGUAGE:
"X will work with Y central bank to study the feasibility
of distributed ledger technology for..."

Research agreements often produce white papers or internal reports but don't necessarily lead to pilots or deployment.

Level 3: Proof of Concept (PoC)

• Technical demonstration

• Limited functionality tested

• Usually internal (not public-facing)

• Validates specific capabilities

• Technology is being seriously evaluated

• Real technical work, not just talk

• But still testing, not committing

• May be one of several PoCs

SUCCESS RATE TO PRODUCTION: ~15%

EXAMPLE LANGUAGE:
"X successfully demonstrated its platform capabilities
in a proof of concept with Y central bank..."

PoCs are more significant than studies but still don't indicate commitment. Many central banks run PoCs with multiple vendors simultaneously.

Level 4: Pilot Program

• Limited real-world deployment

• Actual users (though restricted)

• Specific use cases tested

• Time-bound (6-18 months typical)

• Serious consideration

• Real commitment of resources

• But still testing, not production

• Success not guaranteed

SUCCESS RATE TO PRODUCTION: ~20%

EXAMPLE LANGUAGE:
"X announced a pilot program with Y central bank
to test digital currency for [specific use case]..."

Pilots are the threshold where announcements become more meaningful. Real money is spent, real users interact with the system, and real data is collected.

However, the pilot-to-production transition rate is still only about 20%. Most pilots end without production deployment—either the technology doesn't meet requirements, political conditions change, or priorities shift.

Level 5: Production Contract

• Actual deployment to public

• Long-term commitment (multi-year)

• Significant revenue for vendor

• Central bank dependent on vendor

• THE ONLY THING THAT ACTUALLY COUNTS

• Real adoption, not just testing

• Proven product-market fit

• Reference for other sales

SUCCESS RATE TO PRODUCTION: 100% (by definition)

EXAMPLE LANGUAGE:
"Y central bank announced that [CBDC name] is now
available to the public, powered by X technology..."

Production contracts are the only partnerships that matter for revenue and validation. Everything else is pre-revenue positioning.

Applying this framework to Ripple's announced CBDC engagements:

RIPPLE CBDC PARTNERSHIP STAGES (as of late 2025):

PILOT STAGE:
├── Palau (since 2022) - Stablecoin pilot, not CBDC
├── Bhutan (since 2022) - Digital Ngultrum pilot
├── Montenegro (since 2023) - Digital currency strategy/pilot
├── Georgia (since 2023) - Digital Lari pilot
└── Colombia (since 2023) - CBDC platform pilot

MULTI-VENDOR PARTICIPATION:
└── Hong Kong (2023) - Participated in e-HKD program
    (not exclusive, one of many vendors)

PRODUCTION:
└── None

THE 4+ UNANNOUNCED:
└── Unknown - Possibly earlier-stage than pilots
    (MoUs, studies, or confidential discussions)

Key observations:

1. No production deployments: After 3+ years, none of Ripple's partnerships have reached production. Every single one remains in pilot or earlier stages.

2. Longest-running still piloting: Palau and Bhutan were announced in 2022. Three years later, neither has deployed a production CBDC.

3. Palau isn't actually a CBDC: Palau uses USD and has no sovereign currency to digitize. The Palau project is a government-issued stablecoin, not a central bank digital currency. This distinction matters.

4. Hong Kong was participation, not partnership: Ripple was one of many vendors in HKMA's e-HKD pilot program. It was not an exclusive or preferential relationship.

This analysis isn't meant to diminish Ripple's progress—all CBDC vendors have similar profiles. R3 and ConsenSys have numerous pilot programs but also no major production deployments (except for Cambodia's Bakong, which uses Soramitsu's technology). The CBDC market is genuinely nascent.

But it does provide context for evaluating partnership announcements. The gap between "10 partnerships" and "zero production deployments" is significant and worth understanding.

Understanding how partnership announcements are crafted helps decode what they actually mean:

Common Announcement Patterns:

PATTERN 1: VAGUE SCOPE

Announcement: "X will work with Y central bank to explore
the potential of distributed ledger technology for enhancing
payment efficiency."

- Very early stage (MoU or research)
- No specific project defined
- May never progress beyond this

Red flag: No specific deliverables or timeline mentioned

PATTERN 2: EMPHASIS ON EXPLORATION

Announcement: "Y central bank has selected X as a technology
partner to evaluate CBDC implementation options."

- Evaluation phase (study or PoC)
- X is being considered, not chosen
- Other vendors may be evaluated too

Red flag: "Evaluate" or "explore" rather than "implement"

PATTERN 3: PILOT WITHOUT TIMELINE

Announcement: "X and Y central bank announce pilot program
for digital currency innovation."

- Pilot stage (good progress)
- But no commitment to production
- Could run indefinitely or end quietly

Red flag: No production timeline or success criteria defined

PATTERN 4: RECYCLED ANNOUNCEMENTS

Announcement: "X continues partnership with Y central bank,
entering new phase of collaboration."

- Original announcement was a while ago
- Limited progress to report
- "New phase" may just mean continued existence

Red flag: Previous announcement was 1+ years ago with no 
production update

When evaluating a central bank partnership announcement—from Ripple or any vendor—ask these questions:

Question 1: Is there a central bank confirmation?

Legitimate partnerships are announced by both parties. If only the vendor is announcing, be skeptical. Check the central bank's official communications.

Question 2: What stage is this actually?

Map the announcement language to the partnership spectrum. "Explore," "evaluate," and "pilot" mean very different things than "deploy" or "launch."

Question 3: What's the realistic timeline to production?

Even optimistic CBDC timelines are measured in years. If no production timeline is mentioned, assume it's 5+ years away—if ever.

Question 4: Is this exclusive?

Many central banks evaluate multiple vendors simultaneously. Being selected for a pilot doesn't mean being selected for production.

Question 5: What's the counterparty's motivation?

Small economies often partner with vendors for technology access and international visibility. This is legitimate but different from G20 adoption.

Question 6: What would constitute success?

If the announcement doesn't define success criteria, there's no way to hold the parties accountable for progress.

Question 7: How does this compare to competitors' announcements?

Context matters. If all CBDC vendors have similar partnership counts and stages, any individual announcement is less significant.

PARTNERSHIP QUALITY QUICK ASSESSMENT:

□ Confirmed by central bank (not just vendor)?
□ Specific scope and deliverables defined?
□ Production timeline mentioned?
□ Exclusive relationship (or one of many)?
□ Economy size >10 million population?
□ Genuine central bank (not just government)?
□ First announcement <2 years ago with progress updates?

SCORING:
7/7 checks: Probably significant
4-6 checks: Worth monitoring
1-3 checks: Likely overstated
0 checks: Almost certainly marketing

Ripple's strongest partnership (Bhutan) scores ~4/7:
✓ Confirmed by central bank (Royal Monetary Authority)
✓ Specific scope (Digital Ngultrum)
✗ No production timeline
✗ Not clear if exclusive
✗ Population 800,000 (under threshold)
✓ Genuine central bank
✗ First announcement 3+ years ago, still piloting

Assessment: Worth monitoring but not proof of breakthrough

✅ Central bank technology decisions involve multiple stakeholders with veto power: The complexity of CBDC procurement explains slow progress across all vendors.

✅ Sovereignty concerns dominate technical considerations: Central banks will choose inferior technology if it offers greater control.

✅ Different partnership types have vastly different significance: MoUs and pilots shouldn't be conflated with production deployments.

✅ Large economies typically build in-house: The vendor opportunity is primarily with smaller economies.

⚠️ Whether any vendor's pilot will reach production: The ~20% historical pilot-to-production rate may improve or worsen as the market matures.

⚠️ How political environments will evolve: Anti-CBDC sentiment (especially in the US) creates unpredictable risks for all vendors.

⚠️ Which vendors will emerge as leaders: The competitive landscape remains fluid, with no clear winner yet.

📌 Conflating announcements with adoption: Marketing claims about "partnerships" often obscure the lack of production deployments.

📌 Assuming small-economy wins prove large-economy viability: The stakeholder dynamics, technical requirements, and political considerations are entirely different.

📌 Ignoring the 2025 strategic pivots: Both Ripple and competitors are de-emphasizing CBDC messaging, which signals something about market reality.

Central bank CBDC procurement is a long, complex, politically-influenced process that moves in years, not quarters. All vendor partnership announcements should be evaluated skeptically, with clear understanding of what stage they represent and how far production remains. Ripple's CBDC partnerships are real engagements with real central banks, but none have reached production after 3+ years, and all are concentrated in small economies. This is comparable to competitors' positions—the entire market is nascent—but it's important to calibrate expectations against the hype.

Assignment: Create a comprehensive stakeholder analysis for a hypothetical central bank evaluating CBDC platform vendors.

Requirements:

Part 1: Stakeholder Identification (30%)

For a mid-sized economy central bank (population 20-50 million, developed financial system), identify:

• All stakeholder groups involved in CBDC platform vendor selection
• Key decision-makers within each group (titles/roles)
• Reporting relationships and approval authorities

Present as an organizational diagram with clear hierarchy.

Part 2: Priority Mapping (40%)

For each stakeholder group identified, analyze:

1. Top 3 priorities when evaluating CBDC vendors
2. Key concerns or "veto triggers" that would cause them to block a vendor
3. Information sources they trust (who do they listen to?)
4. How they would evaluate a vendor like Ripple specifically

Create a stakeholder priority matrix (groups × priorities) with supporting rationale.

Part 3: Decision Path Analysis (30%)

Map the likely decision path from initial vendor engagement to production deployment:

1. Key milestones and gates
2. Which stakeholders are involved at each stage
3. Typical timeline for each phase
4. Points where partnerships commonly stall or fail

Present as a decision flowchart with timeline estimates.

• Completeness of stakeholder identification (20%)
• Realism of priority mapping (30%)
• Sophistication of decision path analysis (30%)
• Quality of presentation/visualization (10%)
• Insight specific to blockchain/CBDC vendors (10%)

Time investment: 3-4 hours
Value: This framework becomes your tool for evaluating any CBDC partnership announcement—you'll understand who had to approve it, what it took to get there, and what remains before production.

1. Stakeholder Analysis (Tests Understanding of Decision Dynamics):

A central bank technical team recommends Vendor A for a CBDC platform, but the central bank's board rejects the recommendation and chooses Vendor B instead. Which is the MOST likely explanation?

A) The technical team made an error in their evaluation
B) Vendor B offered a significantly lower price
C) Vendor A had political or reputational concerns that outweighed technical merit
D) The board simply overruled the experts without reason

Correct Answer: C
Explanation: As the lesson explains, political acceptability often trumps technical capability in central bank decisions. The board (representing leadership stakeholders) prioritizes reputation and political risk over technical excellence. Vendor A's recommendation from technical teams would typically be well-founded technically, but factors like regulatory issues (e.g., Ripple's SEC case), geopolitical concerns, or association with controversial sectors can create veto conditions at the leadership level. Price (B) is typically a lower priority for central banks, and arbitrary overruling (D) is rare—there's usually a reason, even if not publicly stated.

2. Partnership Classification (Tests Spectrum Understanding):

A press release states: "X Corp announced it will work with the Central Bank of Y to explore potential applications of blockchain technology for enhancing payment system efficiency." What stage of partnership does this most likely represent?

A) Production contract
B) Pilot program
C) Proof of concept
D) MoU or early research stage

Correct Answer: D
Explanation: The language is the key: "explore potential applications" indicates very early-stage engagement—likely an MoU or research agreement. Production contracts (A) would reference "deployment" or "launch." Pilot programs (B) would mention "testing with users" or "live pilot." PoCs (C) would reference specific "demonstration" or "validation" of capabilities. The vague language about "exploring" and "potential" typically indicates the lowest commitment level in the partnership spectrum, with less than 5% likelihood of reaching production.

3. Priority Analysis (Tests Understanding of Central Bank Values):

A CBDC platform vendor claims their technology can process 100,000 transactions per second, far exceeding any competitor. However, the vendor is based in a country that recently imposed sanctions on several nations. How would most major central banks likely respond to this vendor?

A) Prioritize the technical superiority and overlook geopolitical concerns
B) Request a detailed sanctions compliance report before proceeding
C) Likely disqualify the vendor regardless of technical capability due to sovereignty and political risks
D) Ask the vendor to relocate to a neutral jurisdiction

Correct Answer: C
Explanation: Sovereignty and political acceptability rank higher than technical capability in central bank priorities. A vendor from a country with active sanctions programs creates multiple risks: potential secondary sanctions exposure, geopolitical complications with sanctioned nations, and questions about long-term reliability if political situations change. Central banks prioritize "good enough" technology from politically acceptable sources over superior technology with political baggage. While compliance reports (B) might be requested in marginal cases, a vendor with clear geopolitical complications would typically be screened out early.

4. Production Reality (Tests Critical Thinking):

As of late 2025, how many of Ripple's announced central bank CBDC partnerships have resulted in production deployments serving the general public?

A) 10 or more
B) 5
C) 2-3
D) Zero

Correct Answer: D
Explanation: Despite announcing partnerships with Palau, Bhutan, Montenegro, Georgia, Colombia, and participating in Hong Kong's program, none of Ripple's CBDC engagements have reached production deployment. All remain in pilot or earlier stages. Palau's project (a stablecoin, not technically a CBDC since Palau uses USD) is in pilot. Bhutan's Digital Ngultrum remains in development. Montenegro and Georgia are in pilot phases. This isn't unique to Ripple—the entire CBDC platform vendor market shows similar patterns—but it provides essential context for evaluating partnership announcements versus actual market adoption.

5. Skeptical Analysis (Tests Framework Application):

You read a headline: "Ripple Secures Major Partnership with Central Bank for CBDC Development." Which question is MOST important to ask first when evaluating this announcement?

A) What is XRP's price reaction?
B) Is the partnership confirmed by the central bank, not just Ripple?
C) How many other Ripple partnerships have been announced?
D) What are analysts predicting for XRP price targets?

Correct Answer: B
Explanation: The first critical question for any partnership announcement is verification—is this confirmed by both parties? Legitimate partnerships are announced jointly. If only the vendor is making the announcement, the terms may be overstated or the "partnership" may be much less significant than implied. Central banks are typically conservative in their communications and won't announce partnerships they haven't approved. Price reactions (A, D) are irrelevant to evaluating the announcement's substance. Partnership count (C) is contextual information but doesn't address the specific announcement's validity.

For Next Lesson:
Review the typical 7-phase CBDC development journey, from initial research to full deployment. Lesson 2 will map where each Ripple partnership sits in this multi-year timeline, helping you understand how far production actually remains.

End of Lesson 1

Total words: ~6,800
Estimated completion time: 55 minutes reading + 3-4 hours for deliverable exercise

Teaching Philosophy:
The goal isn't to bash Ripple's CBDC efforts—they're genuinely real partnerships. The goal is to help students evaluate them accurately, which requires understanding the gap between announcements and production. This lesson provides context that makes later partnership-specific lessons more meaningful.

Deliverable Purpose:
Forces students to internalize the complexity of central bank decision-making by mapping it themselves. The exercise produces a reusable framework for evaluating future announcements—not just absorbing the lesson content but creating a tool for independent analysis.