Build the payment batch, send it for approval by amount band, then deliver the approved instruction to the bank. An unapproved instruction cannot enter a batch; the same item can never enter two.
Instructions come from four sources; they merge into one batch and each stays on record with its source.
Once an item enters a batch it is bound to its source; the same instalment or invoice cannot enter a second batch.
One, two or three signatures are required depending on the thresholds. The number needed is frozen at request time and cannot be lowered later by changing the threshold.
A requester cannot sign their own batch; the rule is enforced in the database. Changing the band table itself is also subject to approval.
Even if the user who built the batch is on the signature list, they cannot approve their own batch. The rule cannot be bypassed from the application layer.
The band table in force when the batch was opened applies. Whether the threshold is later raised or lowered, that batch keeps its signature count.
The batch opens but cannot be approved. It does not sit silently in the queue; it is reported as a configuration error.
ISO 20022 pain.001 and bank-format files are generated; you upload them to your bank. The download is recorded — an approved batch that was never downloaded lands on the attention list.
An approved instruction is delivered to the bank through a licensed open banking provider. Tideon holds no payment initiation licence; it produces the instruction and hands it to the provider.
Which route is used is decided per bank and per organisation.
The bank response is processed per instruction. If one IBAN in a batch is wrong, only that instruction is rejected and the rest go through.
Accepted and received are not the same — the bank may have received an instruction without deciding on it yet. The two are shown separately.