Struct MT103

pub struct MT103 {

    pub field_20: Field20,
    pub field_13c: Option<Vec<Field13C>>,
    pub field_23b: Field23B,
    pub field_23e: Option<Vec<Field23E>>,
    pub field_26t: Option<Field26T>,
    pub field_32a: Field32A,
    pub field_33b: Option<Field33B>,
    pub field_36: Option<Field36>,
    pub field_50: Field50OrderingCustomerAFK,
    pub field_51a: Option<Field51A>,
    pub field_52: Option<Field52OrderingInstitution>,
    pub field_53: Option<Field53SenderCorrespondent>,
    pub field_54: Option<Field54ReceiverCorrespondent>,
    pub field_55: Option<Field55ThirdReimbursementInstitution>,
    pub field_56: Option<Field56Intermediary>,
    pub field_57: Option<Field57AccountWithInstitution>,
    pub field_59: Field59,
    pub field_70: Option<Field70>,
    pub field_71a: Field71A,
    pub field_71f: Option<Vec<Field71F>>,
    pub field_71g: Option<Field71G>,
    pub field_72: Option<Field72>,
    pub field_77b: Option<Field77B>,
    pub field_77t: Option<Field77T>,
}

MT103: Single Customer Credit Transfer

Purpose

Used to convey funds transfer instructions between financial institutions where the ordering or beneficiary customer (or both) are non-financial institutions. This is the most common payment message in the SWIFT network for retail and commercial payments worldwide.

Scope

This message is:

• Used for clean payment instructions without additional documents
• Applicable for cross-border payments between different countries/currencies
• Used for high-value domestic transfers via SWIFT network
• Not applicable for collection advices, documentary credits, or cover transactions
• Compatible with STP (Straight Through Processing) requirements
• Subject to comprehensive network validation rules for payment integrity

Key Features

• Universal Payment Format: Most widely used SWIFT payment message globally
• STP Compliance: Built-in support for straight-through processing requirements
• REMIT Support: Enhanced remittance information using field 77T for regulatory compliance
• Service Level Options: Multiple processing speeds and cost tiers available
• Charge Allocation Flexibility: OUR/SHA/BEN charge allocation options
• Comprehensive Validation: 18 network validation rules ensure message integrity

Common Use Cases

• International wire transfers for trade settlements and remittances
• Corporate payments for supplier settlements and salary transfers
• High-value domestic payments requiring SWIFT network routing
• Cross-border e-commerce and marketplace settlements
• Foreign exchange spot and forward settlement payments
• Investment and securities transaction settlements
• Emergency and expedited payment transfers

Message Structure

• Field 20: Sender’s Reference (mandatory) - Unique transaction identifier
• Field 13C: Time Indication (optional, repetitive) - Processing time constraints
• Field 23B: Bank Operation Code (mandatory) - Service level (CRED/SPRI/SSTD/SPAY)
• Field 23E: Instruction Code (optional, repetitive) - Special processing instructions
• Field 26T: Transaction Type Code (optional) - Payment category classification
• Field 32A: Value Date/Currency/Amount (mandatory) - Settlement details
• Field 33B: Currency/Instructed Amount (optional) - Original currency before conversion
• Field 36: Exchange Rate (optional) - Rate for currency conversion
• Field 50: Ordering Customer (mandatory) - Customer initiating payment
• Field 51A: Sending Institution (optional) - Institution sending the payment
• Field 52: Ordering Institution (optional) - Institution of ordering customer
• Field 53: Sender’s Correspondent (optional) - Sender’s correspondent bank
• Field 54: Receiver’s Correspondent (optional) - Receiver’s correspondent bank
• Field 56: Intermediary Institution (optional) - Intermediary in payment chain
• Field 57: Account With Institution (optional) - Institution crediting beneficiary
• Field 59: Beneficiary Customer (mandatory) - Final recipient of funds
• Field 70: Remittance Information (optional) - Payment purpose and details
• Field 71A: Details of Charges (mandatory) - Charge allocation (OUR/SHA/BEN)
• Field 71F: Sender’s Charges (optional) - Charges claimed by sender
• Field 71G: Receiver’s Charges (optional) - Charges claimed by receiver
• Field 72: Sender to Receiver Information (optional) - Additional instructions
• Field 77B: Regulatory Reporting (optional) - Compliance reporting information
• Field 77T: Envelope for Remittance Info (optional) - Structured remittance data

Network Validation Rules

• Exchange Rate Logic: Field 36 requirements when currencies differ (C1)
• EU/EEA Requirements: Field 33B validation for specific country combinations (C2)
• Service Level Compatibility: Instruction code restrictions by service level (C3-C6)
• Correspondent Dependencies: Field dependencies for correspondent institutions (C7)
• Charge Allocation: Currency and charge consistency rules (C8-C9)
• STP Restrictions: Service level limitations on intermediary fields (C10-C12)
• Enhanced Validation: Detailed charge handling and instruction code rules (C14-C18)

SRG2025 Status

• Structural Changes: None - MT103 format remains stable
• Enhanced STP: Strengthened straight-through processing requirements
• REMIT Enhancement: Improved structured remittance information support
• Regulatory Compliance: Enhanced field 77B validation for reporting requirements

Integration Considerations

• Banking Systems: Compatible with all major core banking and payment processing systems
• API Integration: Full RESTful API support for modern payment platforms
• Processing Requirements: Supports real-time, same-day, and next-day processing
• Compliance Integration: Built-in AML, sanctions screening, and regulatory reporting hooks

Relationship to Other Messages

• Triggers: Often triggered by customer payment instructions or corporate ERP systems
• Responses: May generate MT910 (confirmation) or MT900 (debit confirmation)
• Related: Works with MT202 (cover payment) and MT940/MT950 (account reporting)
• Alternatives: MT101 (bulk transfers), MT200 (financial institution transfers)
• Status Updates: May receive MT192/MT196/MT199 for status notifications

Fields

field_20: Field20

field_13c: Option<Vec<Field13C>>

field_23b: Field23B

field_23e: Option<Vec<Field23E>>

field_26t: Option<Field26T>

field_32a: Field32A

field_33b: Option<Field33B>

field_36: Option<Field36>

field_50: Field50OrderingCustomerAFK

field_51a: Option<Field51A>

field_52: Option<Field52OrderingInstitution>

field_53: Option<Field53SenderCorrespondent>

field_54: Option<Field54ReceiverCorrespondent>

field_55: Option<Field55ThirdReimbursementInstitution>

field_56: Option<Field56Intermediary>

field_57: Option<Field57AccountWithInstitution>

field_59: Field59

field_70: Option<Field70>

field_71a: Field71A

field_71f: Option<Vec<Field71F>>

field_71g: Option<Field71G>

field_72: Option<Field72>

field_77b: Option<Field77B>

field_77t: Option<Field77T>

Implementations

impl MT103

pub fn validate() -> &'static str

Get validation rules for this message type

impl MT103

pub fn is_stp_compliant(&self) -> bool

Check if this MT103 message is compliant with STP (Straight Through Processing) requirements

STP compliance requires specific options and restrictions when field 23B contains SPRI, SSTD, or SPAY:

• Field 23B contains SPRI/SSTD/SPAY: Enforces strict STP rules
• Field 53a: Must not be option D (C4)
• Field 53B: Party Identifier mandatory if option B used (C5)
• Field 54a: Only option A allowed (C6)
• Field 55a: Only option A allowed (C8)
• Field 56a: Not allowed if SPRI; only A or C if SSTD/SPAY (C10)
• Field 57a: Only options A, C, or D allowed; D requires Party Identifier (C11)
• Field 59a: Account mandatory (C12)
• Field 23E: Restricted codes for SPRI (C3)

pub fn is_remit_message(&self) -> bool

Check if this MT103 message is a REMIT message with enhanced remittance information

REMIT messages are distinguished by:

• Field 77T must be present and contain structured remittance information
• Field 70 is typically not used (replaced by 77T)
• Enhanced remittance data for regulatory compliance

pub fn has_reject_codes(&self) -> bool

Check if this MT103 message contains reject codes

Reject messages are identified by checking:

1. Field 20 (Sender’s Reference) for “REJT” prefix
2. Block 3 field 108 (MUR - Message User Reference) for “REJT”
3. Field 72 (Sender to Receiver Information) containing /REJT/ code

pub fn has_return_codes(&self) -> bool

Check if this MT103 message contains return codes

Return messages are identified by checking:

1. Field 20 (Sender’s Reference) for “RETN” prefix
2. Block 3 field 108 (MUR - Message User Reference) for “RETN”
3. Field 72 (Sender to Receiver Information) containing /RETN/ code

Trait Implementations

impl Clone for MT103

fn clone(&self) -> MT103

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for MT103

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for MT103

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for MT103

fn eq(&self, other: &MT103) -> 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 MT103

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 MT103

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 MT103