FinTS 3.0 and 4.1
galanthus presents FinTS 3.0 and 4.1 as one set of banking workflows. Applications work with accounts, balances, transactions, holdings, transfers, direct debits, standing orders, and approval steps without building a separate command tree for each protocol generation.
The protocol versions differ at the wire boundary, not at the application boundary. The backend selects the appropriate encoding and parser, while callers use shared operations and results. Banks advertise their own service set, so applications discover capabilities before enabling a workflow.
Official protocol references:
Shared business surface
FinTS connections use the same profiles, requests, results, and command names across both protocol generations. This keeps application code focused on the banking operation rather than the bank's message format.
The shared surface covers:
- accounts, balances, transactions, and holdings
- single and instant transfers
- direct debits and standing orders
- transaction approval and decoupled approval
- Verification of Payee
- persisted continuations and resume
Capability discovery remains essential. A bank can support one workflow and omit another regardless of the FinTS generation it advertises.
Protocol boundary
FinTS 3.0 uses the established binary message path. FinTS 4.1 uses its XML builders, parsers, and authenticated-response handling. Backend resolution, dialog state, workflow orchestration, persistence, and result shaping remain shared.
This boundary prevents a second product surface from emerging around the newer
wire format. The command line therefore exposes business commands such as
balances list, transfers sepa, and tan resume, not protocol-versioned
variants of those commands.
Statements and normalisation
Statement data is normalised into the same transaction model before it reaches the caller. CAMT is preferred where the bank supplies it, with MT940 available for connections that use the older statement format. Protocol-specific fields remain available through the relevant payload and diagnostic surfaces without changing the shared result model.
Approval and resume workflows
Transaction authentication number (TAN), decoupled approval, and Verification
of Payee stages use one interruption and continuation model. A workflow can
pause for operator or bank input and resume through tan resume, including
after a process restart.
Persisted continuation material is encrypted at rest. Completion and supersession rules prevent an old continuation from being treated as a new payment instruction.
Duplicate-submission protection
Money-moving workflows keep submission identity and resume state separate from wire encoding. FinTS 4.1 builders may represent a payment differently from FinTS 3.0, but both paths use the same business request, continuation stages, and completion rules. This allows retries and resumed approvals to be handled without silently creating a second instruction.
Capability discovery
Applications ask whether the active bank connection supports the intended operation before offering it. Version negotiation and protocol checks remain close to backend selection, while user-facing code works with business capabilities such as instant transfer, scheduled execution, and supported payment formats.
For the wider module layout and dialog lifecycle, see architecture_reference.md.