Feature catalogue

Scheme participants

A clearing scheme does not know your organisation by name. It knows you by the identity it issued you, through the bank that sponsored you. In South Africa that is a six-digit user code. In the UK it is a Service User Number, in the United States a company identification.

Every payment file you send goes out under that identity, and every return file the scheme sends back is addressed to it. A scheme participant is where you record it.

What you see

Each row names one identity you have been issued.

Column What it means
Key The short name you give the row. You cannot change it later.
Name What this identity is called on screen.
Channel The scheme this identity is valid on.
Participant code The code the scheme issued you.
Sponsoring bank The bank that sponsored the code.
Active A retired identity stays on file so older payment files still read correctly.

Adding an identity

  1. Select Add Scheme Participant.
  2. Enter a Key in lowercase with hyphens, such as collections-eft.
  3. Enter a Name your colleagues will recognise.
  4. Select the Channel the scheme issued this identity for.
  5. Enter the Participant code exactly as the scheme issued it.
  6. Select the Sponsoring bank. It must already be in your bank registry.
  7. Select the Operating entity the code was issued to, or leave it as Bureau.
  8. Select Save, then publish the draft.

A change to a scheme participant waits for a second person to approve it. That is deliberate — see Who approves a change.

One code per sponsoring bank

A scheme issues a code per sponsoring bank. If a legal entity banks with two banks, it holds two identities on the same scheme, and each payment goes out under the one that matches the bank account it settles through.

Woodgrove Bank sponsors code 632005. A second bank sponsors 250655. Both rows are active, both belong to the same legal entity, and both are correct. A payment nominated to the Woodgrove Bank account goes out under 632005.

You cannot hold two active identities for the same entity, scheme and sponsoring bank. The second one is refused, and the message names the row already holding it.

Bureau and owned identities

Leaving the operating entity empty makes the row a bureau identity: one code the whole organisation submits under. That suits an organisation that has been issued a single code.

An identity that names an operating entity belongs to that entity alone.

flowchart TD
    A["A payment is ready to submit"] --> B{"Does this entity<br/>hold its own identity?"}
    B -->|"Yes"| C["Use the entity's own identity"]
    B -->|"No"| D["Use the bureau identity"]
    C --> E{"Is it active, and does its<br/>sponsoring bank match<br/>the account?"}
    E -->|"Yes"| F["The file goes out under that code"]
    E -->|"No"| G["The payment is refused"]
    D --> E

An entity that holds its own identity never falls back to the bureau code. If its own identity has been retired, the payment is refused rather than sent under an identity the entity does not hold. Sending money out under the wrong identity is worse than not sending it.

Retiring and removing

Clear Active to retire an identity. The row stays on file, so older payment files and their returns still read correctly, and a replacement can take its place.

Remove a row only when it was added in error. A payment already recorded against a removed identity keeps the reference, and no new file can be produced for it.

Who approves a change

Changing a participant code redirects every file you send and every return that comes back. It carries the same risk as changing a bank’s branch code, so it is treated the same way: the change is saved as a draft, and publishing it waits for a second person to approve.

Until the approver grants it, files continue to go out under the old code.

What your organisation configures