Struct MT101 

pub struct MT101 {
    pub field_20: Field20,
    pub field_21r: Option<Field21R>,
    pub field_28d: Field28D,
    pub field_50_instructing_party: Option<Field50InstructingParty>,
    pub field_50_ordering_customer: Option<Field50OrderingCustomerFGH>,
    pub field_52a: Option<Field52AccountServicingInstitution>,
    pub field_51a: Option<Field51A>,
    pub field_30: Field30,
    pub field_25: Option<Field25NoOption>,
    pub transactions: Vec<MT101Transaction>,
}

MT101: Request for Transfer

Purpose

Used to request the movement of funds from the ordering customer’s account(s) serviced at the receiving financial institution. This message enables institutions and authorized parties to initiate multiple transactions in a single message with comprehensive transfer details.

Scope

This message is:

• Sent by financial institutions on behalf of non-financial account owners
• Sent by non-financial institution account owners or authorized parties
• Used for moving funds between ordering customer accounts or to third parties
• Applicable for both domestic and cross-border payment requests
• Compatible with bulk payment processing and corporate treasury operations
• Subject to comprehensive network validation rules for transaction integrity

Key Features

• Multi-Transaction Support: Single message can contain multiple transaction requests
• Dual Sequence Architecture: Sequence A (general info) and Sequence B (transaction details)
• Flexible Party Specification: Ordering customer can be specified in either sequence
• Foreign Exchange Support: Built-in support for currency conversion instructions
• Chained Message Capability: Support for large transaction sets across multiple messages
• Regulatory Compliance: Includes regulatory reporting fields for compliance requirements

Common Use Cases

• Corporate bulk payment processing for payroll and supplier payments
• Treasury operations requiring multiple fund transfers
• Cross-border payment requests with currency conversion
• Inter-company fund transfers within corporate groups
• Standing instruction execution for recurring payments
• Cash management and liquidity optimization transfers
• Trade finance settlement instructions

Message Structure

Sequence A (General Information - Mandatory, Single)

• Field 20: Sender’s Reference (mandatory) - Unique message identifier
• Field 21R: Customer Specified Reference (optional) - Customer reference for all transactions
• Field 28D: Message Index/Total (mandatory) - For chained messages
• Field 50: Instructing Party/Ordering Customer (optional) - Party initiating request
• Field 52A: Account Servicing Institution (optional) - Institution holding accounts
• Field 51A: Sending Institution (optional) - Institution sending the message
• Field 30: Requested Execution Date (mandatory) - When transfers should be executed
• Field 25: Account Identification (optional) - Account to be debited

Sequence B (Transaction Details - Mandatory, Repetitive)

• Field 21: Transaction Reference (mandatory) - Unique transaction identifier
• Field 21F: F/X Deal Reference (optional) - Foreign exchange deal reference
• Field 23E: Instruction Code (optional) - Special processing instructions
• Field 32B: Currency/Transaction Amount (mandatory) - Transfer amount and currency
• Field 50: Ordering Customer (optional) - Customer specific to this transaction
• Field 52: Account Servicing Institution (optional) - Institution for this transaction
• Field 56: Intermediary Institution (optional) - Intermediary in payment chain
• Field 57: Account With Institution (optional) - Crediting institution
• Field 59: Beneficiary Customer (mandatory) - Final beneficiary of funds
• Field 70: Remittance Information (optional) - Payment purpose and details
• Field 77B: Regulatory Reporting (optional) - Compliance reporting information
• Field 33B: Currency/Original Amount (optional) - For currency conversion
• Field 71A: Details of Charges (mandatory) - Charge allocation instructions
• Field 25A: Charges Account (optional) - Account for charge debiting
• Field 36: Exchange Rate (optional) - Rate for currency conversion

Network Validation Rules

• Foreign Exchange Logic: If field 36 present, field 21F mandatory (C1)
• Currency Conversion: If field 33B present and amount ≠ 0, field 36 mandatory (C2)
• Party Specification: Field 50a placement rules between sequences (C3, C4)
• Currency Consistency: Currency in field 33B must differ from field 32B (C5)
• Institution Chain: If field 56a present, field 57a mandatory (C7)
• Cross-Transaction: If field 21R present, all 32B currencies must match (C8)
• Chained Messages: All must have same sender’s reference (field 20)

SRG2025 Status

• Structural Changes: None - MT101 format remains stable
• Enhanced Validation: Strengthened rules for cross-border transfers
• Regulatory Reporting: Enhanced field 77B validation for compliance
• API Integration: Improved support for modern banking APIs

Integration Considerations

• Banking Systems: Compatible with core banking and payment processing systems
• API Integration: RESTful API support for modern corporate banking platforms
• Processing Requirements: Supports both real-time and batch processing modes
• Compliance Integration: Built-in regulatory reporting and sanctions screening hooks

Relationship to Other Messages

• Triggers: Often triggered by corporate ERP systems or treasury management platforms
• Responses: Generates MT103 (customer credit transfer) for each transaction
• Related: Works with MT202 for institutional settlement and MT940/MT950 for reporting
• Alternatives: MT100 for single transfers, MT204 for direct debit instructions
• Status Updates: May receive MT192/MT196/MT199 for status notifications

Fields

field_20: Field20

field_21r: Option<Field21R>

field_28d: Field28D

field_50_instructing_party: Option<Field50InstructingParty>

field_50_ordering_customer: Option<Field50OrderingCustomerFGH>

field_52a: Option<Field52AccountServicingInstitution>

field_51a: Option<Field51A>

field_30: Field30

field_25: Option<Field25NoOption>

transactions: Vec<MT101Transaction>

Implementations

impl MT101

pub fn validate() -> &'static str

Get validation rules for this message type

Trait Implementations

impl Clone for MT101

fn clone(&self) -> MT101

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for MT101

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for MT101

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for MT101

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

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 MT101

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 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

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

impl StructuralPartialEq for MT101