DIN 0815/S · PS-12
Banking
EBICS 3.0 bank transport — key custody, the key exchange, and signed ISO 20022 uploads over the customer’s own bank connection.
MOD-04 already produces a valid pain.001 SEPA credit transfer per payment run; today a human downloads it and uploads it in online banking. EBICS is the protocol that removes the manual step, and this is a Platform Service rather than a module feature for one reason above the others: an EBICS subscriber holds RSA private keys that are sufficient to move money, and those keys belong in exactly one place, guarded once. Private keys are AES-256-GCM ciphertext at rest, are never returned by any endpoint, and are reached through one function that takes a purpose rather than a key id. The protocol layer is Node built-ins only — the exclusive XML canonicaliser and the XML-DSig signature are implemented here rather than taken as dependencies. It speaks twenty order types — every one the H005 schema set gives its own order-data structure except H3K — plus the customer protocol the national annexes define, and it reads back what the bank sends: account statements become bookings a module can search, so an incoming payment finds its invoice. Every message it builds is validated against the published schemas on every test run — the EBICS ones, the ISO 20022 statement schemas, and Austria’s stricter subset — and the order-type tables are transcribed rather than guessed. That discipline is what found each of the defects this service has had, including two that no amount of testing against itself would have shown. Nothing in it has yet spoken to a real bank.
Responsibilities
- Subscriber key custody: A005/A006 signing, X002 authentication, E002 encryption
- The EBICS key exchange — INI, HIA, HPB — and a printable INI letter
- A connection goes live only when a human confirms the bank’s key digests
- Signed BTU uploads of any ISO 20022 file, with segmentation and receipts
- A payment file is submitted at most once, and per-connection ceilings hold
- Ask the bank what it has enabled for you — accounts, order types, signature class
- Fetch any file the bank offers, on a schedule you choose per connection
- Account statements read into bookings a module can search by reference, amount or date
- The bank’s own log of what it did with each order, folded into the orders
- The distributed-signature queue: see what awaits a second signature, co-sign it, or cancel it
- Renew the subscriber keys over the wire — no second paper letter
- Lock a compromised subscriber at the bank yourself, without a phone call
- German and Austrian order types, Verification of Payee, and the Austrian payment formats
API surface
- GET /api/banks · GET/POST /api/connections
- POST /api/connections/:key/keys · /ini · /hia · /hpb
- GET /api/connections/:key/ini-letter.pdf
- POST /api/connections/:key/verify-bank-keys · /suspend · /resume · /lock
- GET /api/connections/:key/veu · POST …/veu/detail · /transactions · /sign · /cancel
- POST /api/orders (?validate=1) · GET /api/orders[/:id]
- GET /api/downloads[/:id][/content] · POST /api/tick
CONSUMED BY MOD-04 Invoice & Billing; any module that can produce an ISO 20022 file. A Platform Service never depends on a Business Module.