---
title: 9. Operations
tags: [Part 2]

---

# 9. Operations

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


## 9.1 Monitoring

Detailed monitoring specifications are to be defined by the TAG. The following principles apply:

MAPs MUST implement:
- Audit payload monitoring for all message exchanges
- Endpoint availability monitoring with automated alerting
- Anomaly detection for unusual traffic patterns

MAPs SHOULD implement:
- Transparent status dashboards accessible by connected providers
- Service status API endpoints for programmatic monitoring
- Incident and planned change indicators in the MAP registry

## 9.2 Malicious Behaviour Detection

In all of these scenerios is it not in the commerical interest of MAP to behave in a malicous way and all MAPs will be vetted through the onboarding process. The following scenarios MUST be monitored to detect and prevent malicious or erroneous behaviour that could happen if a MAPs was compromised. This situation is not unique to any type of architecture, hub or peer-to-peer, but within the CSF there are inherent protection mechanisms to help handle these realworld scenarios as follows:

### 9.2.1 Directory Hijacking

A MAP continues to advertise a CP in its directory after the CP has moved to another MAP. **Detection**: The CP will appear in two registries simultaneously, but only one DNS `_mapkey` entry will be valid. **Resolution**: DNS-based conflict resolution identifies the legitimate MAP.

### 9.2.2 Fraudulent CP Advertisement

A MAP advertises a CP that does not belong to it, with an incorrect root domain, attempting to send fraudulent messages. **Detection**: If all DNS entries are referentially correct, automated detection is difficult. **Resolution**: Escalation and severe penalties for the misbehaving MAP. This is monitored through the onboarding and testing process.

### 9.2.3 Traffic Blackholing

A MAP silently drops messages destined for one or more of its CPs. **Detection**: Sending MAPs will observe failed deliveries and timeouts. **Resolution**: Escalation via MAP contact details in the registry.

### 9.2.4 Denial of Service

Due to the trusted nature of MAP-to-MAP connections, a compromised or buggy MAP could launch a denial-of-service attack against another MAP. **Detection**: Unusual traffic volume or patterns. **Resolution**: Implement standard rate limiting and the following protections:

- Reduce response frequency to make the target less appealing
- Classify the source CP as suspicious and broadcast through the directory
- Implement circuit-breaker patterns to stop processing from the offending source
    - Software design practice used to prevent cascading failures in distributed systems, such as microservices. It acts like a safety switch that temporarily blocks calls to an unresponsive or failing service, allowing it time to recover while protecting the main system from wasting resources.The pattern dynamically manages traffic using three primary states:
    - Closed: The system operates normally, and requests flow freely to the dependent service.
    - Open: The failure rate crosses a predefined threshold. The "breaker trips," immediately blocking all requests to prevent further strain or system-wide crashes.
    - Half-Open: After a set timeout, a few test requests are allowed to pass. If they succeed, the system returns to the Closed state; if they fail, it reverts to the Open state.

### 9.2.5 False Contact Information

A MAP advertises incorrect support contact information, redirecting support queries to malicious websites or phone numbers. **Detection**: Manual verification during onboarding and periodic audits. **Resolution**: Escalation and removal from the network.

> More details on detection and protection are included in the TAG's Onboarding and Testing documentation.

## 9.3 Standard Reporting and KPIs

### 9.3.1 Overview

In a distributed exchange model, there is no centralised hub for reporting. This offers advantages:

- **No expensive centralised reporting tool** to fund and maintain
- **No security risks** from a single entity tracking all industry-wide exchange patterns
- **No competition concerns** from one party having visibility of all switching traffic

MAPs have significant opportunities to provide detailed reporting statistics to their CPs and the wider community while meeting any regulatory requirements.

### 9.3.2 Regulatory Reporting

At the time of writing, there are no official Ofcom statistics that must be collected for business switching. This is recorded in the risk register (RK1). A baseline set of mandatory data point collections needs to be established, with consistent calculations published in this document. A method for sharing statistics with Ofcom may be required if they mandate submissions.

### 9.3.3 Industry Reporting

A standard set of industry metrics is to be defined by the TAG and will be included in subsequent versions of the CSF as part of its feature release mechanism allowing CP/MAPs to support this when they are ready.

- Switch Match success/failure rates by sending and receiving CP
- Switch Order completion rates and timelines
- In-session Switch Match failure counts (using an incremented counter in the audit envelope)
- Grouping of failures by volume per CP to identify patterns

> **OTS Gap**: The significant 1107 error ratio currently seen with OTS needs to be addressed. By enabling in-session Switch Match failure counts, the industry can distinguish between, for example, 17 attempts to achieve a successful match (which is 1 success, not 16 failures) and genuine systemic issues.


## 9.4 Outage Notification

The CSF outage notification mechanism is registry-native: operational status is published in the MAP Registry alongside connectivity and contact information. Because MAPs pull each other's registries at up to 5-minute intervals, any status change propagates across the network within one polling cycle — without any separate notification channel, outage calendar, or centralised hub.

The CSF considers traditional outage calendars (as used in OTS) to be outdated. A MAP suffering an incident should not need to telephone a central service desk or update a shared spreadsheet. By publishing status directly in the registry, the network self-heals: other MAPs detect the outage automatically, queue messages accordingly (see [§1.3 Message Delivery Policy](04-message-api.md)), and resume delivery as soon as the outage entry is cleared.

### 9.4.1 Design Principles

- **Registry-native**: Outage state lives in `map/outage[]` in the MAP Registry — the same pull used for CP discovery also delivers operational status.
- **Near-real-time**: At a 5-minute maximum polling interval, all connected MAPs receive updated status within 5 minutes of publication.
- **Pull-based resilience**: If a MAP fails to respond, the receiving MAP checks its cached registry for a declared outage entry. This directly informs the retry and circuit-breaker logic in §1.3.
- **Graceful degradation**: A MAP that detects a `P1` or `P2` incident on a destination SHOULD queue messages and retry rather than immediately failing the CP interaction.
- **Self-clearing**: The publishing MAP adds and removes entries. An entry with a past `end` time SHOULD be removed once service is restored. An absent or empty `outage` array means fully operational — no entry is needed to signal this state.
- **Consistent with monitoring**: The `outage[]` state SHOULD be the source of truth for the MAP's `serviceStatusURI` status page and `serviceStatusServiceURI` API — both SHOULD reflect what the registry publishes.

### 9.4.2 Incident Priority

Each outage entry carries an ITIL-aligned `priority` value, directly linked to the SLA fix targets in [§9.9 of the Operational Excellence specification](../part1-framework/09-operational-excellence.md). An absent or empty `outage` array means the MAP is fully operational — no entry is needed to signal this state.

| Priority | §9.9 Category | CSF Meaning | Receiving MAP Action | SLA Fix Target |
|---|---|---|---|---|
| `P1` | MAP unavailable | Complete MAP outage — all services unavailable for all CPs | Queue ALL messages for ALL services; apply maximum exponential backoff per §1.3; raise an immediate P1 alert; escalate via the outage entry `contact` | Fix within 4 working hours |
| `P2` | CP unavailable | One or more services or CPs unavailable, or significant degradation affecting CP operations | Queue messages for affected services; apply expedited retry intervals; raise an internal alert; consult the outage entry `contact` if failures persist | Fix within 1 working day |
| `P3` | Service degradation | Partial or intermittent degradation — service operates but at reduced capacity or reliability | Continue delivery; apply shorter retry intervals; monitor closely; alert operations if failure rate increases | Fix within 2 working days |

> An absent or empty `outage` array means the MAP is fully operational. No entry is needed to signal this state.

### 9.4.3 Outage Types

| Type | When to Use |
|---|---|
| `PLANNED` | Scheduled maintenance or infrastructure change where service impact is expected. MAPs SHOULD publish planned outages at least **24 hours in advance** where possible. |
| `INCIDENT` | Unplanned failure or degradation. MAPs MUST publish an incident entry as soon as the incident is confirmed (target: **within 15 minutes** of detection). |

### 9.4.4 JSON Structure

The `outage` array is a new field in the `map` section of the CP Registry, positioned after the `contact` array and before `connectivity`. It reuses the same `contact` sub-object for per-outage escalation details. See the full field reference in [§5.4 of the CP Registry API specification](05-directory-api.md).

#### Fully operational — empty array

```json
{
  "map": {
    "name": "myMap",
    "version": "2026-06-05T08:00:00Z00000",
    "outage": []
  }
}
```

#### Planned maintenance window

```json
{
  "map": {
    "name": "myMap",
    "version": "2026-06-06T18:00:00Z00000",
    "outage": [
      {
        "type": "PLANNED",
        "start": "2026-06-07T02:00:00Z",
        "end": "2026-06-07T04:00:00Z",
        "affectedServices": ["GPLBMessages", "OTSMessages"],
        "description": "Scheduled database maintenance. Brief interruptions of up to 30 seconds may occur. Messages will be queued and delivered on completion.",
        "contact": {
          "type": "email",
          "value": "noc@mymapdomain.com",
          "comment": "24/7 NOC — quote this outage entry when contacting"
        }
      }
    ]
  }
}
```

#### Active incident (P2 — single service)

```json
{
  "map": {
    "name": "myMap",
    "version": "2026-06-05T11:42:00Z00000",
    "outage": [
      {
        "priority": "P2",
        "type": "INCIDENT",
        "start": "2026-06-05T11:38:00Z",
        "affectedServices": ["GPLBMessages"],
        "description": "Letterbox API for GPLBMessages is not responding. Engineering team engaged. ETA for resolution: 30 minutes.",
        "contact": {
          "type": "phone",
          "value": "01111 999999",
          "comment": "Major incident bridge — for MAP technical contacts only"
        }
      }
    ]
  }
}
```

#### Active incident (P1 — complete MAP outage)

```json
{
  "map": {
    "name": "myMap",
    "version": "2026-06-05T11:42:00Z00000",
    "outage": [
      {
        "priority": "P1",
        "type": "INCIDENT",
        "start": "2026-06-05T11:38:00Z",
        "description": "MAP infrastructure failure. All services unavailable. Engineering team engaged. ETA: 1 hour.",
        "contact": {
          "type": "phone",
          "value": "01111 999999",
          "comment": "Major incident bridge — for MAP technical contacts only"
        }
      }
    ]
  }
}
```

#### Multiple concurrent entries

A MAP may publish multiple entries — for example, a forthcoming planned outage alongside an active incident on a different service:

```json
{
  "map": {
    "name": "myMap",
    "version": "2026-06-05T11:42:00Z00000",
    "outage": [
      {
        "priority": "P2",
        "type": "INCIDENT",
        "start": "2026-06-05T11:38:00Z",
        "affectedServices": ["GPLBMessages"],
        "description": "GPLBMessages SwitchMatchResponses unavailable. Engineering engaged. ETA: 30 minutes.",
        "contact": { "type": "phone", "value": "01111 999999", "comment": "Major incident bridge" }
      },
      {
        "type": "PLANNED",
        "start": "2026-06-07T02:00:00Z",
        "end": "2026-06-07T04:00:00Z",
        "affectedServices": ["GPLBMessages"],
        "description": "Scheduled GPLB letterbox maintenance window.",
        "contact": { "type": "email", "value": "noc@mymapdomain.com" }
      }
    ]
  }
}
```

When multiple entries are present, the **highest priority** (lowest number) for a given service determines the action taken by receiving MAPs for that service.

### 9.4.5 Field Reference

| JSON Path | Description | Type | Required |
|---|---|---|---|
| `map/outage[]` | Array of current incident or planned maintenance entries. An empty array or absent field means fully operational. MAPs implementing outage notification SHOULD always include this field, even as an empty array, to signal participation. | Object Array | Yes (empty if operational) |
| `map/outage[]/priority` | ITIL incident priority aligned to §9.9 SLA targets: `P1` (MAP unavailable — fix within 4 working hours), `P2` (CP unavailable — fix within 1 working day), `P3` (service degradation — fix within 2 working days). This is the primary severity indicator. See §9.4.2. | String (enum) | Yes for `INCIDENT`, No for `PLANNED`|
| `map/outage[]/type` | Outage type: `PLANNED` or `INCIDENT`. See §9.4.3. | String (enum) | Yes |
| `map/outage[]/start` | Start time of the outage or maintenance window (ISO 8601 UTC). | DateTime | Yes |
| `map/outage[]/end` | Expected or actual end time (ISO 8601 UTC). For active incidents where resolution time is unknown, omit until the ETA is established. MAPs MUST add or update this field as the ETA becomes known. | DateTime | Optional |
| `map/outage[]/affectedServices` | Routing group names (matching `map/routingGroups[]/name`) covered by this entry. If absent or empty, **all services** on this MAP are considered affected. | String Array | Optional |
| `map/outage[]/description` | Human-readable status narrative. SHOULD include: what is affected, current status, ETA for resolution (if known), and any available workaround. Updated as the incident evolves. | String | Yes |
| `map/outage[]/contact` | Escalation contact specific to this outage (e.g. NOC phone number, incident bridge). Uses the same structure as a `map/contact[]` entry. | Object | Optional |
| `map/outage[]/contact/type` | Contact type: `phone`, `email`, or `url`. | String (enum) | Yes (if contact present) |
| `map/outage[]/contact/value` | Contact value (number, address, or URL). | String | Yes (if contact present) |
| `map/outage[]/contact/comment` | Usage instructions — e.g. reference numbers, bridge PINs, or when to use this contact. | String | Optional |

### 9.4.6 Receiving MAP Behaviour

When a MAP fetches another MAP's CP Registry, it MUST process the `outage` array as follows:

**Step 1 — Determine effective priority per service**

For each service in `map/connectivity/services[]`:

1. Collect all `outage[]` entries that reference that service in `affectedServices`, or have no `affectedServices` restriction (no restriction means all services are affected).
2. If any such entry carries `priority: "P1"`, the effective priority for that service is **P1**.
3. Otherwise, if any such entry carries `priority: "P2"`, the effective priority is **P2**.
4. Otherwise, if any such entry carries `priority: "P3"`, the effective priority is **P3**.
5. If no matching entries exist, the service is **fully operational** — proceed with normal delivery.

**Step 2 — Apply delivery policy**

| Effective Priority | Action |
|---|---|
| Fully operational (no entries) | Deliver messages normally |
| `P3` | Continue delivery; apply shorter retry intervals; monitor closely; alert operations if failure rate increases |
| `P2` | Queue messages for affected services; apply expedited retry intervals; raise an internal alert; consult the outage entry `contact` if failures persist |
| `P1` | Queue ALL messages for ALL services; apply maximum exponential backoff per §1.3; raise an immediate P1 alert; escalate via the outage entry `contact` |

**Step 3 — Handle unexpected failures without a declared outage**

If a MAP fails to respond and has **no** outage entry in its registry, the receiving MAP SHOULD:

1. Attempt delivery using the normal retry and backoff policy (§1.3)
2. Re-pull the source MAP's registry at the next poll cycle
3. If an outage entry subsequently appears (the MAP published one after the failure began), treat it as declared and act accordingly
4. If no entry appears after repeated failures, escalate via the MAP's `map/contact[]` entries — the absence of a declared outage when the MAP is unreachable is itself an escalation trigger

### 9.4.7 MAP Obligations

**Planned Outages**

- MAPs MUST publish a `PLANNED` entry at least **24 hours before** any maintenance with expected service impact
- The entry MUST include a realistic `end` time and a `priority` classification — typically `P3` for routine maintenance; `P2` where CP operations are expected to be significantly affected
- If the maintenance completes early, the MAP MUST remove the entry promptly
- If impact extends beyond the declared `end`, the MAP MUST update the entry immediately

**Incidents**

- MAPs MUST publish an `INCIDENT` entry within **15 minutes** of incident confirmation
- The entry MUST include a `priority` classification. The declared `priority` commits the publishing MAP to the corresponding SLA fix target in §9.9
- The initial entry MAY carry a brief `description` if full impact is still being assessed — it MUST be updated as the situation develops
- If the incident escalates — for example, from a single service affected (`P2`) to complete MAP unavailability (`P1`) — the MAP MUST update `priority` and `description` immediately
- MAPs MUST update `priority` and `description` as the incident evolves (e.g., downgrading from `P1` to `P2` on partial recovery)
- MAPs MUST remove the entry within **30 minutes** of confirmed full recovery
- Leaving stale entries causes unnecessary queuing by other MAPs — timely clearance is a network-wide obligation

### 9.4.8 Relationship to map.status and Monitoring

The `outage` array is distinct from the `map/status` lifecycle field:

| Mechanism | Purpose | Values |
|---|---|---|
| `map/status` | Administrative / lifecycle state — used for onboarding and suspension | `ACTIVE`, `TEST`, `SUSPEND` |
| `map/outage[]` | Operational state — real-time ITIL incident priority | `P1`, `P2`, `P3` entries (absent = fully operational) |

A MAP that is `ACTIVE` in `map/status` may simultaneously carry P1/P2/P3 entries in `map/outage[]` during an incident. A MAP with `map/status: "SUSPEND"` would not normally publish outage entries — the suspension itself signals unavailability.

The `outage[]` array SHOULD be the single source of truth for the MAP's operational status pages: the `serviceStatusURI` human-readable page and the `serviceStatusServiceURI` API endpoint SHOULD derive their published status from the same underlying state, ensuring consistency between what the registry advertises and what external observers see.

### 9.4.9 Feature Advertising

MAPs that implement the outage notification mechanism SHOULD advertise the `outage-notification` feature in their `map/csf/features[]` array (see design proposal §6.1 of the Review Tracker):

```json
"csf": {
  "versions": ["2.0"],
  "currentVersion": "2.0",
  "features": ["outage-notification", "status-api"]
}
```

A MAP that does not advertise `outage-notification` should be treated by receiving MAPs as if its `outage[]` is always empty (GREEN) — but its status signal cannot be relied upon.

## 9.5 Risk Register

The following risk register records risks identified across the MAP membership:

| Date | ID | Description | Status | Impact | Likelihood | Owner |
|---|---|---|---|---|---|---|
| 2025-03-20 | RK1 | **Regulatory and industry reporting requirements** — No official Ofcom statistics mandated for business switching. Need baseline mandatory data points with consistent open calculations. In-session Switch Match failure counting needs to be resolved. | Discovery | Low | High | TBD |
| 2025-04-09 | RK2 | **CP and MAP due diligence checks** — When onboarding, the sponsor is expected to complete typical credit checks, company registration, VAT registration, trading history, fraud, and ICO Data Protection registration checks. This is an industry-wide gap, not specific to CSF. | TBD | Medium | Low | TBD |
| 2025-04-09 | RK3 | **Data retention policy** — Like due diligence, this is a broader industry discussion. Must address across both OTS and SforB to determine suitable retention policies and archiving/destruction methods acceptable to Data Controllers (CPs). | TBD | TBD | TBD | TBD |


## 9.6 The Right to Block

The right to block is a **protective mechanism, not a competitive tool**. A MAP may temporarily suspend routing to or from another MAP or CP when network integrity, security, or compliance obligations require it. No central authority approves a block — the mechanism is self-administering — but each MAP's obligations under the Membership Agreement (MoU) govern when a block is legitimate, and impose strict notification and escalation duties.

### 9.6.1 Principles

- **Protection-first**: Blocking exists to protect the network, CPs, and end-customers — not to disadvantage competitors
- **Proportionality**: The response must match the threat. Automatic technical blocks are the lightest touch; governance escalation is the most severe
- **Transparency**: The blocking MAP MUST notify the affected party promptly and document the grounds
- **Time-limited**: All blocks MUST be reviewed at defined intervals. An indefinite block requires governance oversight
- **Self-healing**: Reinstatement SHOULD be immediate once the triggering condition is resolved

### 9.6.2 Grounds for Blocking

Three categories define legitimate grounds:

**Category A — Technical / Security**

An immediate block is permitted without prior notification:

| Trigger | Example |
|---|---|
| DoS or traffic flooding | Inbound MAP-to-MAP message rate exceeds the agreed cap by more than 10× |
| Malformed or malicious payloads | Repeated messages failing DKIM signature validation or containing injection attempts |
| Credential or key compromise | A MAP's signing key is reported or confirmed compromised |
| Active fraud | A MAP advertises CPs it does not own (§9.2.2) |

**Category B — Operational / SLA**

A notification attempt SHOULD be made before imposing the block:

| Trigger | Example |
|---|---|
| Persistent unresponsiveness | A MAP unreachable for more than 4 continuous hours with no `outage[]` entry published (§9.4) |
| Repeated SLA breaches | Three or more Priority 1 SLA breaches (§9.9) within a rolling 30-day window |
| Stale registry data | CP Registry not updated for more than 48 hours with no declared reason |
| Unresolved security vulnerability | A critical vulnerability unpatched beyond the agreed remediation window |

**Category C — Governance / MoU**

Formal written notification to GPLB-SG MUST precede or accompany the block:

| Trigger | Example |
|---|---|
| Material MoU breach | Persistent refusal to comply with TAG-ratified obligations |
| Network integrity risk | Evidence that a MAP poses a systemic risk to the CSF network |
| Regulatory enforcement | A MAP is subject to enforcement action that affects its CSF participation |

### 9.6.3 Blocking Procedure

Blocks operate at three tiers:

| Tier | Grounds | Decided By | Max Unilateral Duration | Notification Deadline |
|---|---|---|---|---|
| **T1 Automatic** | Category A | Technical systems (circuit breaker / rate limiter) | Indefinite while threat persists; auto-clears | Notify affected MAP within 4 working hours if block persists |
| **T2 Operational** | Category B | Blocking MAP's authorised personnel | 5 working days | Notify affected MAP within 2 working hours of imposing the block |
| **T3 Governance** | Category C | Blocking MAP initiates; GPLB-SG oversees | Until resolved by governance | Notify affected MAP and GPLB-SG secretary within 1 working day |

**Tier 1 — Automatic Technical Block**

Technical protections (rate limiters, circuit breakers, signature validation) activate automatically. When a block persists beyond 4 working hours, the blocking MAP's operations team MUST notify the affected MAP via its `map/contact[]` entries. The block lifts automatically when the threat condition clears, or is manually lifted after review.

**Tier 2 — Operational Block**

1. Before blocking, the blocking MAP SHOULD attempt to contact the affected MAP via `map/contact[]` to allow resolution
2. If no response within 2 working hours — or if immediate risk exists — the block MAY be imposed without prior contact
3. The blocking MAP MUST notify the affected MAP of: the block, the specific Category B grounds, and the conditions for reinstatement
4. The block MUST be reviewed every 5 working days. If unresolved, the blocking MAP MUST escalate to T3

**Tier 3 — Governance Block**

1. The blocking MAP notifies the GPLB-SG secretary and the affected MAP simultaneously, citing Category C grounds with evidence
2. GPLB-SG facilitates a resolution process within a timeframe agreed by the steering group
3. The blocking MAP may maintain the block during governance proceedings
4. Resolution may include: conditional reinstatement, a formal remediation plan, or suspension of the affected MAP's participation (`map/status: "SUSPEND"`)

### 9.6.4 Escalation Path

```
T1 (automatic)   →  4 working hours  →  Notify affected MAP
T2 (operational) →  5 working days   →  Escalate to GPLB-SG (T3)
T3 (governance)  →  GPLB-SG process  →  Reinstatement or suspension
```

A blocking MAP MUST NOT remain at T2 indefinitely. Escalation to T3 after 5 working days is a duty, not an option.

### 9.6.5 Reinstatement

Reinstatement is as lightweight as the block — no central approval is required for T1 or T2.

**Tier 1**: Auto-reinstated when the threat clears, or manually lifted by the blocking MAP. No formal process required.

**Tier 2**:
1. The affected MAP notifies the blocking MAP that the triggering condition has been resolved, with evidence
2. The blocking MAP MUST confirm or dispute within 1 working day
3. Confirmed: the block is removed immediately
4. Disputed: escalates to T3

**Tier 3**: Reinstatement requires GPLB-SG agreement. The affected MAP submits a reinstatement request with a remediation summary. GPLB-SG may impose conditions (e.g. monitoring period, reporting obligations) before granting full reinstatement.

### 9.6.6 Misuse of the Right to Block

A block imposed without legitimate grounds, or maintained beyond the point of resolution, is itself a MoU breach. An affected MAP that believes it has been blocked improperly may escalate directly to T3 — bypassing the blocking MAP — by notifying the GPLB-SG secretary with evidence. A MAP found to have blocked without grounds, or to have used blocking as a competitive measure, is subject to the same governance remedies as the blocked MAP.

### 9.6.7 MoU and Governance Integration

The right to block takes effect through the MAP Membership Agreement. The MoU MUST include:

- A reference to this section as the governing procedure for all blocks
- An obligation on all MAPs to maintain `map/contact[]` entries reachable within the notification windows above
- An obligation to publish and maintain `map/outage[]` (§9.4) as a precondition for challenging any Category B block raised on grounds of unresponsiveness
- An acknowledgement that T3 blocks may result in formal suspension of MAP participation

The **User Rights documentation** SHOULD reference this section to make clear to CPs that their MAP has both the right and the obligation to block other MAPs in defined circumstances — and that this mechanism exists to protect CP service continuity, not to restrict competition.