Releasing a payment file
A payment file is the instruction your bank acts on. When it leaves, money moves.
So it does not leave on its own. The system builds the file, records exactly what it built, and then waits. A person releases it, and a second person approves that release.
What you see
Open Releases to see every payment file waiting to go out — across all your operating entities, because you release the day’s files, not one entity’s.
Each file shows its channel, its value, and how many payments it contains. Check those three against what you expect before you release anything.
The identity a file goes out under
A file also names its participant — the identity the clearing scheme issued you, through the bank that sponsored it. That identity is what the scheme reads in the file header, and it is what the scheme’s return file is addressed back to.
The system chooses it when the payments are collected, from the entity the payments belong to and the bank account they settle through. You do not pick it per file. If no identity fits, the payments are not collected at all and nothing reaches this queue — the system will not send money out under an identity you do not hold.
The Submissions panel on an operating entity names the participant on each submission, so you can see which identity a day’s payments went out under.
See scheme participants for how these are recorded.
Releasing a file
- Open Releases.
- Check the file’s channel, value, and item count.
- Select Release.
- A second approver signs it off.
Nothing is sent until that second person approves. Until then the file stays in the queue and the money stays put.
Why two people
Approving a collection run and releasing a payment file are separate acts.
The first says “these payments are correct”. The second says “send this file to the bank”. They are deliberately not linked: the person who approved the run may also release the file, and a second approver still has to sign the release.
That is where the payment schemes put the control, and it is where an auditor looks for it.
stateDiagram-v2
[*] --> Prepared: payments collected
Prepared --> AwaitingRelease: file built and attested
AwaitingRelease --> AwaitingApproval: someone releases it
AwaitingApproval --> Sent: a second person approves
AwaitingApproval --> AwaitingRelease: approval refused
Sent --> [*]The attestation
When the system builds a file, it records a fingerprint of the exact bytes it built. The Attested column shows the first part of that fingerprint.
Just before the file goes to the bank, the system fingerprints it again and compares. They must match.
| What happened | What you see |
|---|---|
| The file is unchanged since it was built | It is sent |
| The stored file has been altered | It is refused, and nothing is sent |
| No fingerprint was recorded | It is refused, and nothing is sent |
A refusal is not a delivery failure, and you cannot retry your way past it. A delivery failure means the bank could not be reached, and you can retry that. A refused file means what is stored is not what was built — raise it rather than retry it.
The fingerprint is kept in a record that cannot be edited afterwards, which is what lets anyone prove later what the file contained.
Files generated overnight
End of day builds the day’s payment files but does not send them. They are in the queue the next morning, waiting for you.
This applies to every organisation and cannot be switched off. An unsent payment file is the control.
In a demonstration system
A demonstration or training system can be put in simulation. End of day then releases the day’s payment files itself, standing in for both people, so a demonstration runs end to end without anyone at a keyboard.
It is still a real release. The system asks for the release as one simulated person and approves it as a second, through the same control you use — so what you see is the real thing, not a shortcut past it. Both names read as the simulator, never as one of your people.
Simulation cannot be switched on in a live system. It is refused there whatever the setting says.
What this does not prove
The fingerprint proves what was built and that two people authorised it. It does not prove to your bank that the file came from you — that needs a signing key your bank issues, which is not yet in place.
What your organisation configures
- Which channels you submit on, and which of your accounts fund them.
- Who may release a file — the release permission.
- Who may approve a release, and how many approvers are needed — the approval rule for releasing payment files. Without that rule, no second approver is asked for.