EBICS authentication is built around three customer-side X.509 RSA keypairs that are exchanged with the bank at onboarding: A006 (authentication), E002 (encryption), and X002 (signing). The customer generates the keypairs, prints the public-key hash on a paper "Initialisation Letter" (the INI letter), and posts or hand-delivers it to the bank for one-time activation.
A006 is the authentication key — used to sign every EBICS request envelope so the bank knows it is talking to the right corporate. E002 is the encryption key — the bank encrypts file-download responses with the customer's E002 public key so only the corporate can decrypt them. X002 is the signing key on EBICS TS (Transactional Signature) — each payment instruction is individually signed with X002 so the bank can prove a specific corporate user authorised that specific transaction.
Key sizes are 2048-bit RSA today; some banks (BNP Paribas, Société Générale) now also accept 3072-bit and have a 4096-bit upgrade path on their roadmap. The keys are stored in a secure-element (smartcard, HSM, or cloud HSM) on the corporate side — never on disk in cleartext.
Key rotation is annual at most banks, with the new public key sent through an in-band EBICS HCA (Change of Authentication keys) or HSA (Change of Subscriber's keys) request. The bank counter-signs to confirm activation; the old key is decommissioned after a grace window.
iso-compliant does not hold EBICS keys — the channel layer is the customer's responsibility. The split is deliberate: the corporate retains its existing bank relationship and the EBICS credentials never leave their network. iso-compliant ships the ISO 20022 file that the customer's EBICS client signs and uploads.
Not implemented in iso-compliant; see FUTURES.md (managed EBICS channel) for the optional Phase-4 add-on.