Some orders are too important to leave to a single person. When you submit an order that requires distributed signatures, the bank parks it instead of executing it. The order stays pending until every required signature has been collected — and each signer is a separate EBICS subscriber with their own keyring. One person prepares the payment, another approves it, and only then does the bank process the order.
That is the point of Electronic Distributed Signatures (EDS): segregation of duties, enforced by the bank rather than by your internal policy. Nobody can create and release a payment on their own, and the audit trail of who signed what, and when, comes from the bank itself.
Each signer works independently, from their own machine, at whatever time suits them. There is no central coordinator and no waiting for a group session — the bank simply holds the order until the required number of signatures exists.
Distributed signatures are not a separate workflow you set up — they are an attribute of an order. If your bank requires a distributed signature for a given order type, every order submitted through that order type is held for approval, and the orders waiting for you appear automatically.
For step-by-step visual instructions check out the presentation slides — they walk you through completing the setup.
Nothing to configure up front: distributed signatures are an attribute of an order, not a workflow. If your bank requires them for an order type, every order submitted through it is held automatically and appears for approval.
The only decision is whether a submission should be held — the ES flag, an option next to the order type marking it as requiring a distributed signature before processing continues. Offered for the upload order types BTU, FUL, CCT, CDD, CIP, CDB, XE2, XE3 and YCT:
Bank Operations — flag a manual order before executing it.
Scheduler Jobs — flag a scheduled upload, so every file it sends is held for approval.
Tracker Subscriptions — flag the transfer and settlement downloads.
Flagging a scheduler job joins both halves: uploads go out on schedule, the bank holds each one, a second person approves.
Open the Distributed Signatures page and select the bank connection. The list shows every order that bank is holding — nothing to claim or accept, whatever is waiting is already there. Each row shows order ID, amount, party and account, who submitted it and when, and Num Sig (Done / Req): required against collected, so 1 / 2 is one signature from execution.
Before committing, review the contents: preview the file in the built-in viewer, or download {order_id}.xml and inspect it externally.
Sign approves the order. Your signature is bound to the order's hash and counts towards the required number; once the last one arrives the bank processes it, nothing resubmitted.
Cancel rejects it. The order is withdrawn and other signers released — cleaner than signing and later recalling over a wrong amount, beneficiary or duplicate.
Bulk Sign and Bulk Cancel handle a whole selection at once, one transaction per order, stopping at the first rejection.
Your signature is issued as the connection's own subscriber, not the originator.
Orders that must carry more than one signature are submitted and held by the bank. They are listed per connection, where you review each one and then sign or cancel it. The bank processes an order once every required signature has been collected.
No. If your bank requires distributed signatures for an order type, the hold happens automatically and pending orders appear in the page. You only set the ES flag where you want a particular submission held.
The signature belongs to the subscriber whose keyring performs the request, defaulting to the connection's own subscriber. "Submitted by" names the originator, which in this workflow is a different party.
Sign approves the order and counts towards the required signatures. Cancel withdraws it and releases the other signers.
Yes. Preview opens it in the built-in viewer, download saves {order_id}.xml for external tooling. Both return the complete order data, which is recommended for high-value orders.