---
title: 8. RCPID Management
tags: [Part 1]

---

# 8. RCPID Management

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

## 8.1 What is an RCPID?

A Retail Communications Provider Identifier (RCPID) is a unique identifier assigned to a CP brand for the purpose of message exchange. Each RCPID maps 1:1 to a human-readable brand name that appears in search and drop-down lists used by CPs when initiating a Switch Match.

## 8.2 Why UUIDv4?

The CSF adopts **UUIDv4** (RFC 4122) as the RCPID format, replacing the 4-character alphanumeric codes used by OTS.

### Problems with the OTS Format

The OTS format (`Rxxx` — e.g., RGXD, RYHC) has several limitations:

- **Collision risk**: With only 4 characters, the probability of duplication increases as more CPs join for business switching (expected tenfold increase over OTS)
- **Human confusion**: Similar codes are easily mistaken (e.g., RYHC and RYCH are different brands but commonly confused — and they can exist in the same MAP)
- **MAP coupling**: If prefixes are tied to MAPs, changing MAP requires changing RCPID, which is costly and disruptive
- **Scalability**: The format does not scale for business switching where CPs may have multiple brands requiring separate identifiers

### Benefits of UUIDv4

UUIDv4 addresses all of these issues:

- **Virtually zero collision risk**: With 122 bits of randomness, the odds of collision between any two UUIDs are 1 in 2.71 x 10^18. One would need to generate 1 billion UUIDs per second for 85 years to have a 50% chance of a single collision.
- **Self-allocation**: MAPs can generate RCPIDs independently without central coordination
- **No human bias**: Machine-generated identifiers eliminate human-readable confusion
- **Portability**: The RCPID stays with the CP for life, regardless of which MAP they use
- **Data continuity**: All historical data (time-series, audit records, reporting) remains consistent as CPs move between MAPs

**Example RCPID**: `d8322d80-92c8-4906-a408-f1d2daf7e03d`

### Compatibility with OTS

The UUIDv4 format does not preclude any CP or MAP (including TOTSCo) from continuing to use the OTS `Rxxx` format internally. MAPs can maintain a mapping between their internal codes and the UUIDv4 RCPID used for SforB message exchange.

The SforB Message Specification defines the source and destination identity fields as strings with a maximum length of 256 characters. UUIDv4 (36 characters including hyphens) fits well within this constraint.

## 8.3 Allocation Process

1. The MAP generates a UUIDv4 for the new CP brand
2. The MAP provisionally allocates it to the CP
3. Before going live, the MAP pulls all other MAP directories and checks for collisions
4. If no collision is detected, the MAP publishes the RCPID in its registry
5. If a collision is detected (extremely unlikely), the MAP generates a new UUID and repeats

> **Responsibility**: It is the MAP's responsibility to ensure no duplication or collisions occur. The MAP MUST check the generated ID against the directory before allocating it to a CP and advertising it as live.

## 8.4 RCPID Lifecycle

### Allocation

An RCPID is allocated to a CP brand and remains associated with that brand **for life**. This helps with:

- CPs moving between MAPs
- Future brand consolidation or growth
- Mergers and acquisitions
- Consistent time-series data and historical reporting across all MAPs

### MAP Transitions

When a CP moves between MAPs:

1. The RCPID **does not change** — it remains constant and unique across the network
2. The new MAP adds the existing RCPID to its CP Registry
3. The old MAP removes the RCPID from its CP Registry
4. Other MAPs detect the change through CP Registry synchronisation and DNS verification

This ensures seamless continuity for in-flight orders and network-wide consistency.

### Retirement

When a CP brand is dissolved or merged, the RCPID is retired and retained in an archived state for historical reporting purposes. It MUST NOT be reused for a different brand.  While there is no centralised record each MAP will be responsible for hold a legagcy record and avoiding the risk of re-using for a nominal period of time. Once all inflight orders are resolved and SORs expired then there is a low risk asociated with reuse. It is also very unlikely, given UUID v4 size and the method suggested for picking new ones, that anyone will pick a previously used RCPID. 

## 8.5 Handling Exports During Transitions

When a CP moves to a new MAP, the in-flight order data must be transferred:

1. **Export with ID mapping**: On a valid "RCPID Status" request, the old MAP provides a standardised JSON export of all in-flight orders for the specified RCPID
2. **Validation**: The request is validated by checking that the RCPID's DNS entry now points to the MAP making the request
3. **CP Registry updates**: The old MAP removes the CP from its CP Registry before responding, ensuring no duplicate entries exist
4. **Verification**: The new MAP verifies the accuracy of the RCPIDs and ensures no collisions

> For the complete transition process including in-flight order handling, see [Part 2: CP Transitions](../part2-implementation/07-cp-transitions.md).

## 8.6 Summary

| Aspect | OTS (Legacy) | CSF |
|---|---|---|
| Format | 4-character alpha (Rxxx) | UUIDv4 (36 characters) |
| Allocation | Centralised or MAP-specific | MAP self-allocates |
| Collision risk | Moderate (grows with scale) | Negligible (1 in 2.71 x 10^18) |
| Portability | Tied to MAP (prefix-based) | Follows the CP for life |
| Human readability | Confusing (RYHC vs RYCH) | Not human-readable (by design) |
| Scalability | Limited for business switching | Unlimited |