Struct MT205 

pub struct MT205 {

    pub field_20: Field20,
    pub field_21: Field21NoOption,
    pub field_13c: Option<Vec<Field13C>>,
    pub field_32a: Field32A,
    pub field_52: Field52OrderingInstitution,
    pub field_53: Option<Field53SenderCorrespondent>,
    pub field_56: Option<Field56Intermediary>,
    pub field_57: Option<Field57AccountWithInstitution>,
    pub field_58: Field58,
    pub field_72: Option<Field72>,
    pub field_50_seq_b: Option<Field50OrderingCustomerAFK>,
    pub field_52_seq_b: Option<Field52OrderingInstitution>,
    pub field_56_seq_b: Option<Field56Intermediary>,
    pub field_57_seq_b: Option<Field57AccountWithInstitution>,
    pub field_59_seq_b: Option<Field59>,
    pub field_70_seq_b: Option<Field70>,
    pub field_72_seq_b: Option<Field72>,
    pub field_33b_seq_b: Option<Field33B>,
}

MT205: General Financial Institution Transfer

Purpose

Used for financial institution transfers where the ordering institution is always identified. This message type is specifically designed for transfers initiated by a financial institution for its own account or on behalf of its customers, with mandatory ordering institution details.

Scope

This message is:

• Sent between financial institutions for institutional transfers
• Used when the ordering institution must be explicitly identified (unlike MT202)
• Applicable for both direct transfers and cover payments
• Compatible with correspondent banking arrangements
• Subject to enhanced validation rules for cross-border payments
• Includes contingency processing capabilities for qualifying transfers

Key Features

• Mandatory Ordering Institution: Field 52 is always required (key difference from MT202)
• Dual Sequence Architecture:
  • Sequence A: Institution-to-institution transfer details
  • Sequence B: Underlying customer payment details (for cover payments)
• Enhanced Validation: Sophisticated rules for institution identification and routing
• Cover Payment Support: Full support for cover payment scenarios with customer details
• Settlement Flexibility: Compatible with various settlement mechanisms
• Cross-Currency Capability: Support for foreign exchange operations

Common Use Cases

• Central bank operations requiring explicit ordering institution identification
• Correspondent banking transfers with mandatory institution details
• Cross-border institutional payments
• Treasury operations between financial institutions
• Cover payments for underlying customer transfers
• Settlement of securities transactions
• Liquidity management between institutions

Message Structure

Sequence A (Institution Transfer Details)

• Field 20: Transaction Reference (mandatory) - Unique transaction identifier
• Field 21: Related Reference (mandatory) - Reference to related transaction/message
• Field 13C: Time Indication (optional, repetitive) - Processing time constraints
• Field 32A: Value Date/Currency/Amount (mandatory) - Settlement amount and timing
• Field 52: Ordering Institution (mandatory) - Institution initiating the transfer
• Field 53: Sender’s Correspondent (optional) - Sender’s correspondent bank
• Field 56: Intermediary Institution (optional) - Intermediary in payment chain
• Field 57: Account With Institution (optional) - Crediting institution
• Field 58: Beneficiary Institution (mandatory) - Final beneficiary institution
• Field 72: Sender to Receiver Information (optional) - Additional instructions

Sequence B (Cover Payment Details - Optional)

• Field 50: Ordering Customer (optional) - Underlying ordering customer
• Field 52: Ordering Institution (optional) - Additional ordering institution details
• Field 56: Intermediary Institution (optional) - Cover payment intermediary
• Field 57: Account With Institution (optional) - Cover payment account details
• Field 59: Beneficiary Customer (optional) - Underlying beneficiary customer
• Field 70: Remittance Information (optional) - Payment purpose and details
• Field 72: Sender to Receiver Info (optional) - Cover-specific instructions
• Field 33B: Currency/Instructed Amount (optional) - Original currency/amount

Network Validation Rules

• Field 52 Mandatory: Ordering institution validation (field 52) - key difference from MT202
• Cover Payment Structure: Validation of Sequence B customer fields presence
• Cross-Currency Validation: Currency consistency between fields 32A and 33B
• Correspondent Chain: Banking chain validation for intermediary institutions
• Settlement Method: Determination based on correspondent relationships
• Time Indication: Compliance checking for CLS/TARGET timing constraints
• REJT/RETN Indicators: Structured validation of reject/return codes in field 72

SRG2025 Status

• Structural Changes: None - MT205 structure remains unchanged
• Enhanced Validation: Additional network rules for institutional transfers
• Contingency Processing: Enhanced processing rules for qualifying transfers
• Cross-Border Compliance: Strengthened validation for international payments

Integration Considerations

• Banking Systems: Compatible with real-time gross settlement (RTGS) systems
• Central Bank Operations: Direct integration with central bank settlement mechanisms
• API Integration: RESTful API support for modern banking infrastructure
• Processing Requirements: Support for time-critical payment processing

Relationship to Other Messages

• Triggers: Can be triggered by MT202COV or customer payment instructions
• Responses: May generate MT202, MT210 (notice to receive), or MT292 (reject)
• Related: Works with MT950/MT940 for account reporting and confirmation
• Alternatives: MT202 for transfers without mandatory ordering institution
• Cover Payments: Supports underlying MT103 customer credit transfers

Fields

field_20: Field20

field_21: Field21NoOption

field_13c: Option<Vec<Field13C>>

field_32a: Field32A

field_52: Field52OrderingInstitution

field_53: Option<Field53SenderCorrespondent>

field_56: Option<Field56Intermediary>

field_57: Option<Field57AccountWithInstitution>

field_58: Field58

field_72: Option<Field72>

field_50_seq_b: Option<Field50OrderingCustomerAFK>

field_52_seq_b: Option<Field52OrderingInstitution>

field_56_seq_b: Option<Field56Intermediary>

field_57_seq_b: Option<Field57AccountWithInstitution>

field_59_seq_b: Option<Field59>

field_70_seq_b: Option<Field70>

field_72_seq_b: Option<Field72>

field_33b_seq_b: Option<Field33B>

Implementations

impl MT205

pub fn validate() -> &'static str

Get validation rules for this message type

impl MT205

pub fn has_reject_codes(&self) -> bool

Check if this MT205 message contains reject codes

Reject messages are identified by checking:

1. Field 20 (Transaction Reference) for “REJT” prefix or content
2. Field 72 (Sender to Receiver Information) containing /REJT/ codes
3. Additional structured reject information in field 72

pub fn has_return_codes(&self) -> bool

Check if this MT205 message contains return codes

Return messages are identified by checking:

1. Field 20 (Transaction Reference) for “RETN” prefix or content
2. Field 72 (Sender to Receiver Information) containing /RETN/ codes
3. Additional structured return information in field 72

pub fn is_cover_message(&self) -> bool

Check if this MT205 message is a Cover (COV) message

COV messages are distinguished by:

• Presence of Sequence B customer fields (50a, 59a)
• Additional underlying customer credit transfer details

Based on the MT205 specification: “Cover Detection: Based on presence of Sequence B customer fields (50a, 59a)”

Trait Implementations

impl Clone for MT205

fn clone(&self) -> MT205

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for MT205

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for MT205

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for MT205

fn eq(&self, other: &MT205) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for MT205

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl SwiftMessageBody for MT205

fn message_type() -> &'static str

Get the message type identifier (e.g., “103”, “202”)

fn from_fields( fields: HashMap<String, Vec<(String, usize)>>, ) -> SwiftResult<Self>

Create from field map with sequential consumption tracking

fn from_fields_with_config( fields: HashMap<String, Vec<(String, usize)>>, config: &ParserConfig, ) -> Result<ParseResult<Self>, ParseError>

Create from field map with configuration for error collection

fn to_fields(&self) -> HashMap<String, Vec<String>>

Convert to field map

fn required_fields() -> Vec<&'static str>

Get required field tags for this message type

fn optional_fields() -> Vec<&'static str>

Get optional field tags for this message type

fn to_ordered_fields(&self) -> Vec<(String, String)>

Convert to ordered field list for MT serialization Returns fields in the correct sequence order for multi-sequence messages

impl StructuralPartialEq for MT205