ISO 20022 is a boundary, not a file format

What the public implementation shows

SIPS Connect separates CoreBank DTOs, incoming payment DTOs, message builders, parsers, status roles, and a documented protocol-mapping matrix instead of treating ISO generation as one serialization function.

The repository places semantic transformation in a dedicated SIPS.ISO20022 package and keeps orchestration in SIPS.Core. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleCorrect XML is necessary; preserving payment meaning across the boundary is the real job.

The decision behind the mechanism

This separation makes each mapping rule inspectable: identifiers, agents, parties, amounts, reasons, and statuses can be tested independently from transport and persistence.

A syntactically valid message can still be financially wrong when a local status, party role, or identifier is mapped into the wrong ISO meaning. 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.

• Keep local DTOs separate from generated ISO schema classes.
• Test builder and parser behavior as a round-trip contract.
• Record message-role decisions such as pacs.002 direction explicitly.
• Version mapping changes with representative payload evidence.

How the control should be operated

Teams should review message changes as contract changes, using schema decisions, mapping matrices, representative payloads, and parser/builder tests together.

That review model makes interoperability defects visible before they become ambiguous payment outcomes. 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.