The RTGS Directory and CRDM Common Reference Data Management

The RTGS Directory is the published list of every party that can be addressed in the RTGS component of T2. Each entry holds the BIC, the full name of the institution, the participation type, the national central bank that supervises the participant, and the direct participant that settles for the party when the party holds no account of its own. A bank that looks up a BIC in the directory can see at once whether the party is a direct participant with its own RTGS Dedicated Cash Account, or an addressable BIC that settles through another bank. The directory is the single source of truth for addressing, and every T2 bank must use it. CRDM, which stands for Common Reference Data Management, is the system that stores the reference data behind the directory. Banks and national central banks enter party data, account data, participation data and access rights into CRDM, and CRDM validates the data, stores it centrally and distributes it to T2, T2S and TIPS. When Commerzbank registers a new branch in Madrid as a multi-addressee, it enters the branch BIC, the link to the head office direct participant and the access rights into CRDM. Only after CRDM accepts the entry can the branch send or receive payments in T2. CRDM is common across the TARGET services, so one entry serves more than one service. A bank that registers a party in CRDM for T2 can also use the same party data for TIPS, where the same BIC may hold a TIPS Dedicated Cash Account, and for T2S, where the same legal entity may hold a securities account. That shared data removes duplication and removes the risk that T2 and TIPS hold different names or different BICs for the same bank. A change to a bank name, a BIC or a participation type is made once in CRDM, and it flows to every service that uses the data. Directory updates follow a daily cycle, and banks must plan around it. CRDM changes made during the day are validated, then loaded into the RTGS Directory for the next business day. A bank that registers a new addressable BIC on a Tuesday cannot receive payments through that BIC until the updated directory is in force, usually the next business day. A bank that sends a EUR 100,000 payment to the new BIC on the same Tuesday will have the payment rejected, because the directory it checked does not yet hold the new entry. Operations teams must check the effective date, not just the entry date. Banks download the RTGS Directory regularly, usually weekly, and load it into their payment engines for validation. The payment engine checks the instructed agent BIC, the creditor agent BIC and any other BIC in the pacs.008 against the directory before it sends the message to T2. A bank that skips the download, or that loads an old copy, risks sending payments to BICs that have left the system or to participation types that have changed. A weekly download, a version check and a test payment to a changed BIC are simple controls that keep addressing accurate and keep customer payments moving. Worked example with numbers: a bank registers a new addressable BIC on a Tuesday, and the change is validated in CRDM during the day, then loaded into the RTGS Directory for the next business day. On Wednesday the new BIC appears in the directory as code 08, and other banks can address payments to it, but a payment sent on Tuesday to the new BIC fails, because the directory the sending bank downloaded on Monday does not list it yet. The bank that registered the BIC must therefore tell its correspondents the date from which the BIC is live, and must not promise customers that payments will arrive before that date. Failure and recovery: the directory fails when a bank uses a stale copy, and the failure is a payment rejected for an unknown BIC. A bank that downloads the directory weekly may hold a copy that is six days old, and in those six days a BIC may have been removed, a branch may have closed, or a participation type may have changed. The recovery is a fresh download and a resend, but the payment has already lost a day, and the customer must be told the new value date. A bank must therefore download the directory daily, or at least before its first payment run, and must log the version it used for each payment, so that an investigation can prove which directory was in force when the payment was sent. For a business analyst, product owner or subject matter expert, the directory requirement must state the download cadence, the version that is in force, and the validation that runs before a payment is sent. The requirement must name CRDM as the source of the reference data and the RTGS Directory as the published list, and must state that a payment addressed to a BIC that is not in the directory must be rejected before sending, not after. The test pack must include a payment to a newly registered BIC, a payment to a removed BIC, and a payment to a BIC whose participation type changed, because each case exercises a different directory rule. Source: European Central Bank, TARGET services; last reviewed 7 November 2026.