Investigation result

  Your LUKB contact is right, and there's a real bug here — but it's worth being precise about which part is wrong, because that's exactly what explains the ZKB-vs-LUKB difference.

  There are two separate artifacts in the INI step, and they're built by different code paths:

  1. The electronic INI request (the XML sent over the wire) — this is correct/compliant.

  In SignaturePubKeyOrderDataElement.build() (src/main/java/org/kopi/ebics/xml/SignaturePubKeyOrderDataElement.java:46-62), the order data always embeds the full X.509 certificate via X509Data, using getA005Certificate() (which returns getEncoded() — the DER
  bytes). The pubkey-value alternative is commented out. The request is sent in the urn:org:ebics:H005 namespace (INIRequestElement.java:58), i.e. EBICS 3.0. So the request the bank receives is fine, and the bank server accepts it and returns OK. This is the same
  for ZKB and LUKB — which is why it "worked" with ZKB.

  2. The INI letter (the printed/signed document) — this is where the bug is.

  The letter hash is built conditionally on a useCertificate() flag (A005Letter.java:46-71, same in E002Letter/X002Letter):
  - useCertificate() == true → getHash(certificate) = SHA-256 of the DER-encoded certificate ✅ (the H005 way)
  - useCertificate() == false → getHash(publicKey) = SHA-256 of the public key (modulus+exponent, the old EBICS 2.5 / A005 way) ❌

  And the flag defaults to false:
  - CLI: hard-coded boolean useCertificates = false; (EbicsClient.java:515)
  - Parameterized launcher: resolveUseCertificate() returns false unless EBICS_USE_CERTIFICATE=true or EBICS_SIGNATURE_VERSION=A006 (ParameterizedEbicsClientLauncher.java:227-234)

  So with the defaults, the letter prints the SHA-256 of the public key, while the request transmits an X.509 certificate. Per EBICS 3.0 spec ch. 4.4.1.2.3, the bank verifies that the hash on the letter matches the certificate it received — and these two don't
  match.

  Fix options

  - Quick workaround (no code change): run with the certificate hash forced on — e.g. EBICS_USE_CERTIFICATE=true for the parameterized launcher, then re-generate and re-send the INI/HIA letters.
  - Proper fix: since the INI/HIA requests unconditionally send the X.509 certificate under H005, the letters should unconditionally hash the certificate too — i.e. drop the useCertificate() branch in A005Letter/E002Letter/X002Letter (or default it to true) so the
   printed digest is always SHA-256 of the DER cert.