Party Management

Register and retrieve the beneficiary parties used when instructing payments through Funds Controllers.

Overview

Party Management enables participants to register creditors (payment recipients) and debtors (payment senders) with a Funds Controller. Registered parties are referenced when instructing payments such as FI to FI Customer Credit Transfer.

All create requests are asynchronous — a 202 Accepted response confirms the request was received, and the outcome is delivered as a webhook event.

Three versions are available for creditor management:

• V1 — flat schema, sent directly to the Funds Controller using their specific field requirements
• V2 — structured schema with Individual/Company discrimination; supports per-Funds-Controller schema discovery via GET /v2/creditors/schemas/create
• V3 — same structured, schema-discoverable model as V2, with per-Funds-Controller schema discovery via GET /v3/creditors/schemas/create

Debtor management is available in V1 (flat schema) and V3 (structured schema with per-Funds-Controller schema discovery via GET /v3/debtors/schemas/create).

Creating a Creditor

1. Submit — POST to /v1/creditors, /v2/creditors or /v3/creditors with the beneficiary details and FundsControllerCode
2. Acknowledgement — RTGS.global returns 202 Accepted
3. Funds Controller processing — The Funds Controller validates and registers the beneficiary
4. Result — A success or failure event is delivered via webhook

Event	Description
global.rtgs.creditorCreatedV1	Creditor registered successfully (V1)
global.rtgs.createCreditorFailedV1	Registration failed — SchemaFailures and GenericFailures indicate the cause (V1)
global.rtgs.creditorCreatedV2	Creditor registered successfully (V2)
global.rtgs.createCreditorFailedV2	Registration failed — Errors dictionary indicates the cause (V2)
global.rtgs.creditorCreatedV3	Creditor registered successfully (V3)
global.rtgs.createCreditorFailedV3	Registration failed — Errors dictionary indicates the cause (V3)

Creating a Debtor

The debtor flow follows the same pattern as creditor creation, using POST /v1/debtors or POST /v3/debtors. V3 uses the same structured, schema-discoverable model as creditor V3 — retrieve the fields a Funds Controller requires via GET /v3/debtors/schemas/create.

1. Submit — POST to /v1/debtors or /v3/debtors with the debtor details and FundsControllerCode
2. Acknowledgement — RTGS.global returns 202 Accepted
3. Funds Controller processing — The Funds Controller validates and registers the debtor
4. Result — A success or failure event is delivered via webhook

Event	Description
global.rtgs.debtorCreatedV1	Debtor registered successfully (V1)
global.rtgs.createDebtorFailedV1	Registration failed — SchemaFailures and GenericFailures indicate the cause (V1)
global.rtgs.debtorCreatedV3	Debtor registered successfully (V3)
global.rtgs.createDebtorFailedV3	Registration failed — Errors dictionary indicates the cause (V3)

Retrieving Parties

Use GET /v1/creditors, GET /v2/creditors or GET /v3/creditors with a FundsControllerCode query parameter to list registered creditors. Use GET /v1/debtors or GET /v3/debtors for debtors.

For V2 and V3, use the schemas/create and schemas/list endpoints to retrieve JSON Schema documents describing the fields required by a specific Funds Controller — field requirements vary per Funds Controller:

• Creditors — GET /v2/creditors/schemas/create · GET /v2/creditors/schemas/list · GET /v3/creditors/schemas/create · GET /v3/creditors/schemas/list
• Debtors — GET /v3/debtors/schemas/create · GET /v3/debtors/schemas/list