Struct MT107 

pub struct MT107 {

    pub field_20: Field20,
    pub field_23e: Option<Field23E>,
    pub field_21e: Option<Field21E>,
    pub field_30: Field30,
    pub field_51a: Option<Field51A>,
    pub field_50_instructing: Option<Field50InstructingParty>,
    pub field_50_creditor: Option<Field50Creditor>,
    pub field_52: Option<Field52CreditorBank>,
    pub field_26t: Option<Field26T>,
    pub field_77b: Option<Field77B>,
    pub field_71a: Option<Field71A>,
    pub field_72: Option<Field72>,
    pub transactions: Vec<MT107Transaction>,
    pub field_32b: Option<Field32B>,
    pub field_19: Option<Field19>,
    pub field_71f: Option<Field71F>,
    pub field_71g: Option<Field71G>,
    pub field_53: Option<Field53SenderCorrespondent>,
}

MT107: General Direct Debit Message

Purpose

Used for general direct debit instructions where a creditor requests the debit of multiple debtor accounts. This message provides more flexibility than MT104 for complex direct debit scenarios with enhanced authorization control and flexible party identification options.

Scope

This message is:

• Used for general direct debit processing between financial institutions
• Applicable for bulk direct debit operations with flexible authorization control
• Designed for complex direct debit scenarios requiring detailed transaction control
• Compatible with both domestic and cross-border direct debit schemes
• Subject to authorization validation rules for debtor consent management
• Integrated with return processing mechanisms for failed direct debits

Key Features

• Enhanced Flexibility: More sophisticated than MT104 for complex direct debit scenarios
• Authorization Management: Field 23E supports AUTH/NAUT/OTHR authorization status codes
• Party Identification Options: Instructing party can appear in Sequence A or individual transactions
• Return Processing Support: Special handling for returned direct debits with RTND codes
• Settlement Consolidation: Optional settlement sequence for consolidated settlement details
• Multi-Transaction Support: Supports multiple debtor accounts in single message

Common Use Cases

• Corporate direct debit collections for subscription services and utilities
• Bulk salary and pension direct debit processing
• Recurring payment collections for insurance and loan payments
• Cross-border direct debit schemes for international service providers
• Return processing for previously failed direct debit attempts
• Multi-party direct debit scenarios with complex authorization requirements
• Government tax and fee collection via direct debit

Message Structure

Sequence A (General Information)

• Field 20: Transaction Reference (mandatory) - Unique message identifier
• Field 23E: Instruction Code (optional) - Authorization status (AUTH/NAUT/OTHR/RTND)
• Field 21E: Related Reference (optional) - Reference to related message
• Field 30: Execution Date (mandatory) - Date for direct debit execution
• Field 51A: Sending Institution (optional) - Institution sending the message
• Field 50: Instructing Party/Creditor (optional) - Party requesting direct debits
• Field 52: Creditor Bank (optional) - Bank of the creditor
• Field 26T: Transaction Type Code (optional) - Classification of direct debit type
• Field 77B: Regulatory Reporting (optional) - Compliance reporting information
• Field 71A: Details of Charges (optional) - Charge allocation instructions
• Field 72: Sender to Receiver Information (optional) - Additional processing instructions

Sequence B (Transaction Details - Repetitive)

• Field 21: Transaction Reference (mandatory) - Unique reference for each direct debit
• Field 32B: Currency/Amount (mandatory) - Amount to be debited from each account
• Field 59: Debtor (mandatory) - Account and details of party being debited
• Field 23E: Instruction Code (optional) - Transaction-level authorization status
• Field 50: Instructing Party/Creditor (optional) - Transaction-level party identification
• Field 57: Debtor Bank (optional) - Bank holding the debtor account
• Field 70: Remittance Information (optional) - Purpose and details of direct debit
• Field 33B/36: Currency conversion fields for cross-currency direct debits

Sequence C (Settlement Information - Optional)

• Field 32B: Settlement Amount (optional) - Total settlement amount
• Field 19: Sum of Amounts (optional) - Control total for validation
• Field 71F/71G: Charges (optional) - Settlement charges information
• Field 53: Sender’s Correspondent (optional) - Settlement correspondent

Network Validation Rules

• Authorization Consistency: If 23E is AUTH/NAUT/OTHR in Sequence A, same restriction applies to Sequence B
• Party Identification: Instructing party must appear in exactly one sequence (A or B per transaction)
• Return Processing: Field 72 required when 23E = RTND for returned direct debit details
• Currency Conversion: Exchange rate (36) required when 33B currency differs from 32B
• Transaction Limits: Maximum transaction count per message enforced
• Reference Validation: All transaction references must be unique within message
• Authorization Validation: Authorization codes must be consistent with regulatory requirements

SRG2025 Status

• Structural Changes: None - MT107 format remains stable
• Validation Updates: Enhanced authorization validation for regulatory compliance
• Processing Improvements: Improved handling of return processing scenarios
• Compliance Notes: Strengthened regulatory reporting requirements for cross-border transactions

Integration Considerations

• Banking Systems: Compatible with direct debit processing engines and mandate management systems
• API Integration: RESTful API support for modern direct debit collection platforms
• Processing Requirements: Supports batch processing with individual transaction validation
• Compliance Integration: Built-in mandate validation and regulatory reporting capabilities

Relationship to Other Messages

• Triggers: Often triggered by direct debit collection schedules or mandate execution systems
• Responses: May generate MT900/MT910 (confirmations) or status notification messages
• Related: Works with MT104 (simplified direct debits) and account reporting messages
• Alternatives: MT104 for simpler direct debit scenarios without complex authorization
• Status Updates: May receive return or reject messages for failed direct debit attempts

Fields

field_20: Field20

field_23e: Option<Field23E>

field_21e: Option<Field21E>

field_30: Field30

field_51a: Option<Field51A>

field_50_instructing: Option<Field50InstructingParty>

field_50_creditor: Option<Field50Creditor>

field_52: Option<Field52CreditorBank>

field_26t: Option<Field26T>

field_77b: Option<Field77B>

field_71a: Option<Field71A>

field_72: Option<Field72>

transactions: Vec<MT107Transaction>

field_32b: Option<Field32B>

field_19: Option<Field19>

field_71f: Option<Field71F>

field_71g: Option<Field71G>

field_53: Option<Field53SenderCorrespondent>

Implementations

impl MT107

pub fn validate() -> &'static str

Get validation rules for this message type

Trait Implementations

impl Clone for MT107

fn clone(&self) -> MT107

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for MT107

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for MT107

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for MT107

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

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 MT107

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 MT107