fix: deliver every portion of a response the bank spreads over several messages (code 3040)

[phkoenig]

The symptom

When a bank spreads a response over several messages, the data never reaches the caller. Not with an error — with success: true, zero transactions and no warning:

const response = await client.getCreditCardStatements(account, from, to);
// response.success === true
// response.statements === []   // the bank sent 233 transactions

The wider the date range, the more likely it is. A caller has no way to tell this apart from an account that genuinely had no activity, which is what makes it expensive: a sync can report success for weeks while silently losing everything.

What I measured

Berliner Volksbank (GAD backend), credit card account via HKCAZ v1, same account, same day, only the range varied:

Range	Bank's answer	Transactions before	after
40 days	code 20 (ok)	105	105
60 days	code 3040	0	206
75 days	code 3040	0	233

The two returned CAMT documents cover adjacent, non-overlapping periods, so nothing is counted twice.

Three defects, all in the same path

1 · Delivery. handlePartedMessages reassigned its responseMessage parameter to the follow-up message and spliced the assembled segment into that one. The caller still holds the first message, which still contains the unresolved PARTED placeholder — so findSegment finds nothing.

2 · Assembly. The portions were concatenated as raw bytes, on the assumption that a segment continues mid-field. It does not. Each portion is a complete, self-contained response segment: a follow-up HICAZ repeats account and CAMT descriptor before carrying its own share of the documents. Gluing the raw text produced an unparseable segment — the CAMT parser reports Extra text at the end.

3 · Only the first placeholder was resolved. One bank message may carry several response segments. The rest stayed in the tree as PARTED, invisible to findAllSegments.

Separately, Message.decodeSegment compared the segment id with a plain startsWith, so looking for HICAZ also caught HICAZS (and HIEKA caught HIEKAS). A parameter segment held back as PARTED is never decoded. A segment starts with SEGID:number:version, so the colon belongs in the comparison.

What changed

Every portion is decoded on its own, and all of them are placed into the message the caller holds.

Combining the payloads needs to know what they mean, so that step moved to the interactions, which now collect via findAllSegments:

Interaction	How portions combine
CAMT (HICAZ)	append the document lists
SEPA accounts (HISPA)	append the account lists
Credit card (DIKKU)	append the transactions, balance is identical in each
MT940 (HIKAZ)	join — one continuous stream
MT535 (HIWPD)	join — one continuous stream

That distinction matters: joining a list of CAMT documents produces invalid XML, and appending MT940 fragments produces an unparseable stream.

No public API change. A response that fits into one message takes exactly the path it took before.

Tests

src/tests/partedResponse.test.ts, 5 cases: a parted response delivered to the caller's message; portions decoded individually rather than byte-glued; several response segments in one message; a parameter segment (HICAZS) passing through untouched; and the unparted case as a regression guard.

117 tests pass (112 before). There was no test for code 3040 previously, which is why this could go unnoticed.

Scope of verification — please read

The live evidence above comes from one bank and one backend (Berliner Volksbank, GAD, HKCAZ v1). Everything else — MT940, MT535, SEPA, credit card via DIKKU — follows the specification and is covered by tests, but I have not seen a real 3040 response on those paths. The per-interaction combination rules are the part I would look at hardest, since they are where a wrong assumption would show up as corrupted rather than missing data.

Happy to adjust naming, comment density or structure to your preference.

---

Found while tracking down a 69-day gap in a production credit card sync. Written with AI assistance (noted in the commit trailers); the measurements and the review are my own.

[robocode13]

Thank you for this contribution. I myself didn't have this problem before even with a 1.400 transaction statement, but then every bank handles this differently i guess. At least i can confirm that everything i can test with four different banks is still working, so i will adopt this PR.