#8. Commercial Scenarios

Connected Services Framework (CSF) — Part 2: Implementation — Version 2.0

#8.1 Overview

The CSF addresses several commercial scenarios that were not fully covered by OTS. These scenarios are critical for ensuring business continuity, CP autonomy, and consumer/business protection.

#8.2 CP Emergency Migration

CP Emergency Migration is the reactive process by which a CP transfers to a new MAP under one of the §8.2.2 trigger conditions (most often a failing, suspended, removed, or unresponsive MAP). It contrasts with a normal CP transition (§7), which is planned and CP-driven on a commercial timeline. The CSF mandates that every MAP supports emergency on-boarding of an existing CP as a core capability.

#8.2.1 Definition and Scope

Emergency migration applies when the CP needs to move with little or no notice — usually because the current MAP can no longer be relied on to sign, route, or audit the CP's messages. It is not a substitute for a normal transition (§7); it is the framework's safety net.

Under OTS, a CP cannot move its in-flight orders between MAPs without significant manual effort, and the same risk exists if a MAP enters administration. The CSF addresses this by:

• Decoupling the CP from the MAP through DNS-controlled identity (§6)
• Enabling CPs to move freely between MAPs (or across multiple MAPs under different brands)
• Mandating that every MAP supports in-flight order export as a core capability (§4)
• Providing the rcpidStatusRequest flow so a new MAP can reconstruct or import in-flight state from the old MAP (§4) or, when the old MAP is offline, from other MAPs holding the orders

#8.2.2 Triggers

Any one of the following invokes CP Emergency Migration:

Triggers T1, T2, T5 cover the "MAP can't do its job" cases. T3 and T4 are TAG-driven and are also referenced in the draft Anti-Competitive Enforcement clause — to be published as an Appendix to the CSF framework once it has been legally reviewed and signed off by the TAG members (tracked as P-3 in the open-conflicts log). Until the Appendix is published, T3/T4 follow the existing §10.7 graduated enforcement ladder. T6 covers the rare case where the CP itself elects to invoke the emergency process.

#8.2.3 Happy Path — Distressed MAP Still Online

When a MAP is in distress but still operational:

1. The CP establishes a new MAP relationship and updates DNS
2. The new MAP advertises the CP and sends rcpidStatusRequest to the original MAP
3. The original MAP responds with in-flight order exports
4. Other MAPs detect the directory change and update routing

If the CP appears in both directories temporarily, conflict management resolves it automatically using DNS verification (the CP's _mapkey is the tiebreaker — see §6.5).

The new MAP SHOULD advertise the distressed MAP as being in "conflict," signalling other MAPs to verify their CP associations with that MAP.

Migration can be completed in a few hours if the new MAP expedites CP onboarding.

#8.2.4 Unhappy Path — Distressed MAP Offline

If the failing MAP cannot perform exports:

1. The CP contacts a new MAP and completes onboarding
2. The CP uses its own CRM records to identify in-flight orders
3. The new MAP issues rcpidStatusRequest to other MAPs involved in those in-flight orders
4. All new requests use new correlation IDs
5. Switch Matches without Switch Orders can be re-issued (they are not part of the export)

During the offline period:

• The CP will not appear in any directory or drop-down lists
• Messages cannot be exchanged for the affected CPs
• Any order updates must be managed with prospects and supply chains manually

All MAPs can onboard new CPs within hours, so the offline period is not expected to exceed 2 working days.

#8.2.5 Per-Scenario Timing Targets

Three different commitments apply, depending on which path is in play:

These are framework targets; an individual MAP's MoU may commit to tighter numbers commercially.

#8.2.6 Normal Transition vs Emergency Migration — Contrast

#8.2.7 Emergency RACI

This RACI applies to the emergency process specifically. The in-flight-order RACI for normal transitions is in §7.6.

R = Responsible · A = Accountable · C = Consulted · I = Informed

#8.2.8 Fee Guidance

Fees for an emergency migration depend on which trigger applies:

In all cases, the new MAP MUST publish its expedite-onboarding charge alongside its standard onboarding charge (transparency requirement, §10).

#8.2.9 Audit and Retention

Both happy- and unhappy-path emergencies generate an emergency-event log entry that the new MAP MUST persist. The entry SHALL contain at minimum:

• Trigger (T1 – T6 from §8.2.2) and free-text reason
• Timestamps: decision-to-migrate, DNS update, new-registry advertise, first rcpidStatusRequest issued, all completed
• Old MAP RCPID and new MAP RCPID
• List of rcpidStatusRequest correlation IDs issued and which responded
• Outcome: "happy" (all responses received) or "unhappy" (CRM reconstruction used)
• Any in-flight orders re-issued with new correlation IDs

Retention:

• Happy path — exported in-flight order package retained alongside the new MAP's normal CSF audit logs per the data retention policy in §9 (5 years).
• Unhappy path — the CP's CRM-reconstruction record forms the authoritative in-flight set for the affected interval and SHOULD be retained for the same period; the new MAP records the reconstruction inputs received from the CP.
• All rcpidStatusRequest and response messages issued or received during the emergency MUST be persistently logged per §9 audit-log requirements.

#8.2.10 CP Emergency Migration Checklist

• CP contacts new MAP and agrees terms
• New MAP treats the CP as an experienced user (expedited onboarding)
• New PKI keys generated and DNS records updated (_domainkey, _mapkey)
• New MAP advertises CP in its registry
• rcpidStatusRequest issued to original MAP (if available) and affected sibling MAPs
• In-flight order data imported (happy) or reconstructed from CP CRM (unhappy) and reconciled
• Emergency-event audit log entry written (§8.2.9)
• Old MAP marked "in conflict" in the new MAP's directory (where applicable)
• Full operations resume

#8.3 CP Merger, Acquisition, and Consolidation

CPs involved in mergers may need to consolidate brands over time. The CSF supports this through a staged process:

#Stage 1 — Stop Selling

Mark consolidating brands as not accepting new Switch Matches (but still process in-flight orders and handle losses).

#Stage 2 — Asset Migration

Move customer assets from stop-sell brands to the surviving RCPID. During this period:

• The stop-sell brands remain in the directory
• The current MAP continues to handle any losses for those brands
• Care must be taken if this extends over a long period

#Stage 3 — Close In-Flight Orders

Complete all remaining in-flight orders on consolidating brands. For any remaining orders:

• Complete gains
• Cancel losses where appropriate
• Migrate remaining customer assets to the surviving RCPID

#Stage 4 — Remove Brands

Remove stop-sell brands from the MAP's directory. This signals to other MAPs that those CPs no longer exist. The RCPIDs are:

• Retained in time-series data for audit records
• Archived under normal data retention policies
• Never reused for different brands

#8.4 CP Going into Administration

When a CP enters administration with outstanding in-flight orders:

#MAP Responsibilities

1. Hold all in-flight orders: Switching to a CP in administration would have greater impact on end consumers than maintaining the status quo
2. Continue processing outbound switches: All in-flight orders transferring away from the CP in administration MUST continue to be processed, even if the MAP is not being paid
3. Suspend new business: The MAP sets the CP status to SUSPENDED in the directory
   • No new Switch Matches or Switch Orders will be processed
   • Existing customers are locked with their current provider under business continuity terms
4. Await resolution: Continue until the CP is recovered by another party or managed by an appointed insolvency team

#Industry Considerations

The response of a MAP when a CP enters administration MUST be formally defined by each individual MAP and is outside of the scope of the CSF. Refer to OTA2 guidance

#8.5 Summary of Built-in Protections