Completion notifications close the participant loop

What the public implementation shows

The ISO model contains CoreBank completion notification DTOs and the outgoing status handler has dedicated completion-notification tests.

A switch-facing final status is translated into a participant-facing notification rather than exposing raw ISO messages to the CoreBank. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleFinancial completion is useful only when the participant can apply and evidence it safely.

The decision behind the mechanism

The gateway owns the semantic and transport boundary needed to make finality consumable by the participant system.

Without a distinct contract, a final status can be stored locally while the CoreBank remains unaware or receives a notification it cannot safely deduplicate. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Notify only after resolving the status to the correct transaction.
• Make the notification idempotent for the CoreBank.
• Persist delivery attempts separately from financial state.
• Expose unresolved completion notifications to operations.

How the control should be operated

Notification records should preserve transaction identity, final status, attempt history, participant response, and outstanding-delivery state.

Operations can distinguish financial finality from participant notification completeness. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.