Swift connectivity, FIN, FINplus, RMA, security-zone, and MT-to-MX coexistence architecture

Payment core and message preparation

Creates the approved MT or MX instruction and keeps its lifecycle reference.

Kind

application

Owner

Payments technology

Responsibilities

• Choose the correct message and profile
• Preserve business references across MT and MX coexistence

Inputs

• Approved payment
• Route
• Counterparty and profile

Outputs

• FIN MT or FINplus ISO 20022 document

Controls

• Profile validation
• Release entitlement
• No silent MT-to-MX data loss

Failure modes

• Wrong service selected
• Unsupported message after migration milestone
• Truncated party data

Recovery

• Stop before network release
• Repair against the current profile
• Use contingency conversion only where Swift explicitly supports it

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Relationship Management Application policy

Controls whether the institution permits a counterparty to send within the governed Swift relationship and scope.

Kind

control

Owner

Swift security administration

Responsibilities

• Evaluate relationship authorisation
• Maintain approved counterparties and message scope

Inputs

• Counterparty BIC
• Service
• Message scope
• Effective policy

Outputs

• Allow or deny decision with policy evidence

Controls

• Segregation of duties
• Periodic recertification
• Change audit

Failure modes

• Missing authorisation
• Over-broad scope
• Expired relationship

Recovery

• Hold the message
• Correct the relationship through the authorised administration process

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Swift messaging interface

Applies queueing, signing, service selection, acknowledgements, and local message controls.

Kind

gateway

Owner

Swift platform operations

Responsibilities

• Queue and release messages
• Correlate Swift acknowledgements
• Expose operator status

Inputs

• Approved message
• RMA outcome
• Signing authority

Outputs

• Network submission and technical status

Controls

• Dual control
• Queue integrity
• Duplicate detection
• Secure operator access

Failure modes

• Queue stall
• Local NAK
• Lost acknowledgement
• Clock or certificate issue

Recovery

• Reconcile the local queue and network acknowledgement
• Resume from the durable interface state

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Swift secure zone and identity services

Protects credentials, signing authority, administrative access, and the controlled Swift footprint.

Kind

security

Owner

Cybersecurity and Swift security officers

Responsibilities

• Protect identities and secrets
• Separate user, administrator, and service duties
• Monitor the secure zone

Inputs

• Administrative changes
• Signing requests
• Security telemetry

Outputs

• Authenticated identities
• Protected signing operations
• Security alerts

Controls

• Least privilege
• Multi-factor authentication
• Segmentation
• Logging
• Integrity monitoring

Failure modes

• Credential compromise
• Unapproved configuration
• Monitoring outage

Recovery

• Contain the zone
• Revoke and replace credentials
• Reconcile messages and configuration before service restoration

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Resilient Swift connectivity

Carries FIN and FINplus traffic through independently recoverable network paths.

Kind

infrastructure

Owner

Network and Swift infrastructure operations

Responsibilities

• Maintain service connectivity
• Fail over without duplicating business submissions

Inputs

• Encrypted Swift service traffic

Outputs

• Delivered traffic and connectivity telemetry

Controls

• Path diversity
• Change control
• Capacity monitoring
• Failover tests

Failure modes

• Path outage
• Regional connectivity failure
• Asymmetric reachability

Recovery

• Fail over under a tested runbook
• Reconcile queued and acknowledged traffic

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

FIN service

Transports supported MT messages and returns network validation and delivery evidence.

Kind

external-network

Owner

Swift

Responsibilities

• Apply FIN service controls
• Return network acknowledgements and delivery status

Inputs

• FIN MT message

Outputs

• ACK, NAK, delivery status, or network report

Controls

• Network validation
• Service eligibility
• Store-and-forward controls

Failure modes

• NAK
• Service outage
• Unsupported message or release

Recovery

• Correct a NAK before resubmission
• Follow the applicable network continuity procedure

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

FINplus service

Transports ISO 20022 messages under the applicable Swift service and usage guideline.

Kind

external-network

Owner

Swift

Responsibilities

• Apply FINplus service controls
• Carry the selected ISO 20022 business document

Inputs

• Business Application Header and ISO 20022 document

Outputs

• Technical and delivery status

Controls

• Service validation
• Counterparty addressing
• Duplicate controls

Failure modes

• Network rejection
• Profile failure
• Unavailable service

Recovery

• Correct the identified issue
• Use only an authorised contingency path

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Swift operations and security monitoring

Reconciles local queues, network evidence, security alerts, and business outcomes.

Kind

operations

Owner

Swift operations and payment operations

Responsibilities

• Monitor queues and acknowledgements
• Investigate missing or conflicting outcomes
• Coordinate continuity actions

Inputs

• Interface status
• Network acknowledgements
• Security telemetry
• Business state

Outputs

• Resolved incident
• Controlled replay decision
• Audit trail

Controls

• Four-eyes release
• Evidence-based replay
• Incident and change records

Failure modes

• Alert gap
• Unowned queue
• Premature replay

Recovery

• Establish the last confirmed state
• Assign one incident owner
• Reconcile before replay

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Counterparty authorisation

swift-payment-core → swift-rma

Confirm that the relationship and message scope permit release.

Contract

control · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A missing or invalid relationship keeps the message unreleased.

Authorised release

swift-rma → swift-interface

Pass the approved message and policy evidence to the interface.

Contract

control · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A deny result remains visible and cannot be overridden by transport retry.

Identity and signing authority

swift-security-zone → swift-interface

Authorise protected message and administration operations.

Contract

control · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Unavailable or untrusted signing authority stops release.

Encrypted service traffic

swift-interface → swift-connectivity

Carry queued messages and receive technical evidence through resilient connectivity.

Contract

message · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

The interface retains queue state while connectivity is unavailable.

FIN MT traffic

swift-connectivity → swift-fin

Send a supported MT message through FIN.

Contract

message · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A NAK or unavailable service is reconciled before correction or resend.

FINplus MX traffic

swift-connectivity → swift-finplus

Send the ISO 20022 document through FINplus.

Contract

message · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

A network or profile rejection is kept distinct from downstream business processing.

Queue and acknowledgement telemetry

swift-interface → swift-ops

Expose message, queue, acknowledgement, and delivery state to operations.

Contract

operator · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Monitoring gaps raise an incident; they do not imply a failed or unsent payment.

Reconciled network outcome

swift-ops → swift-payment-core

Update the payment only from verified network and business evidence.

Contract

event · operator

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Conflicting evidence enters investigation and does not overwrite final state.

Release one CBPR+ pacs.008 through FINplus

Follow the business message through relationship policy, local security, interface queueing, connectivity, and network evidence.

1. Prepare the profiled message — Ready for release. The payment core produces a current CBPR+ pacs.008 and retains its business references.
2. Check the relationship — Counterparty authorised. The governed relationship and scope permit the exchange.
3. Queue and sign — Locally released. The interface records the release, applies signing authority, and queues the message.
4. Carry the service traffic — Network submitted. The message leaves through the configured Swift connectivity path.
5. FINplus accepts the message — Network accepted. Technical acceptance is recorded; it is not yet proof of beneficiary credit or settlement.
6. Correlate the acknowledgement — Technical outcome reconciled. Operations can connect the network evidence to the business payment without guessing.
7. Update the lifecycle — Submitted to counterparty. The payment state advances only to the outcome proven by the acknowledgement.

RMA relationship blocks release

The counterparty or message scope is not authorised by current relationship policy.

Last confirmed state

The payment message is ready but has not been locally released.

Settlement

No network or settlement submission has occurred.

Funds and entries

Any internal reservation remains under the bank's unreleased-payment policy.

Next owner

Swift security administration and payment operations

Safe action

Keep the message on hold and correct the relationship only through the authorised RMA process.

Evidence required

• Counterparty BIC
• Message/service scope
• RMA policy version
• Approval record

Recovery

• Approve or reject the relationship change
• Re-run release controls
• Retain the original hold evidence

Connectivity fails after local release

The message is locally released but no conclusive network acknowledgement arrives.

Last confirmed state

Locally released; network acceptance is unknown.

Settlement

Unknown; technical uncertainty is not settlement evidence.

Funds and entries

Do not reverse or resend solely because connectivity is down.

Next owner

Swift platform operations with payment operations

Safe action

Reconcile the interface queue, delivery state, and network evidence before failover or replay.

Evidence required

• Queue record
• Message identifier
• Connectivity event
• Network acknowledgement or enquiry

Recovery

• Fail over under the tested runbook
• Reconcile queued traffic
• Replay only under the duplicate policy

Unsupported MT after migration milestone

An upstream system creates an MT instruction no longer supported for the intended payment service.

Last confirmed state

Payment intent exists; no supported network message has been released.

Settlement

No settlement submission has occurred.

Funds and entries

The payment remains unreleased and must not be treated as sent.

Next owner

Migration programme and payment product

Safe action

Use the supported native MX path or an explicitly authorised contingency service; do not invent a conversion.

Evidence required

• Message type
• Service
• Migration milestone
• Current Swift support statement

Recovery

• Route to the supported message path
• Check data-loss implications
• Revalidate and release once

Where should message validation and signing responsibilities sit?

• Central Swift platform — Common controls and operations, but a larger shared dependency.
• Domain-owned interfaces — Closer product ownership, but more secure zones and duplicated controls.
• Shared secure service with domain adapters — Central identity and network control with explicit domain contracts.

Model the trust and recovery boundary first. Product topology follows the institution's scale and security operating model.

How should MT and MX coexistence be handled?

• Native MX at source — Preserves ISO 20022 data and removes conversion dependency.
• Controlled internal conversion — Supports legacy producers but creates mapping and data-loss risk.
• External contingency conversion — May preserve reach only where the service explicitly supports it; functionality and cost differ.

Treat every conversion as a governed transformation with source-to-target lineage. Check current Swift treatment for the exact message and service.