Struct MT210 

pub struct MT210 {
    pub field_20: Field20,
    pub field_25: Option<Field25NoOption>,
    pub field_30: Field30,
    pub sequence: Vec<MT210Sequence>,
}

MT210: Notice to Receive

Purpose

Used to inform a financial institution that funds will be credited to their account. This message serves as advance notification of incoming funds, allowing the receiving institution to prepare for and reconcile expected payments.

Scope

This message is:

• Sent by a financial institution to notify another institution of pending credits
• Used for liquidity management and cash flow planning
• Applicable to various payment scenarios requiring advance notification
• Essential for correspondent banking relationships
• Used in settlement systems requiring pre-advice of incoming funds

Key Features

• Pre-Advice Functionality: Advance notification of incoming payments
• Repetitive Sequence Structure: Multiple payment notifications in single message
• Flexible Identification: Either ordering customer (50) or ordering institution (52) required
• Account Management: Optional account identification for specific crediting
• Multi-Currency Support: Individual currency and amount per sequence
• Correspondent Banking: Support for intermediary institution chains

Common Use Cases

• Correspondent bank payment notifications
• Treasury department cash flow management
• Settlement system pre-advice messages
• Liquidity management notifications
• Expected payment confirmations
• Cross-border payment notifications
• Multi-currency portfolio funding advice

Message Structure

Header Section

• 20: Transaction Reference (mandatory) - Unique message identifier
• 25: Account Identification (optional) - Specific account to be credited
• 30: Value Date (mandatory) - Date when funds will be available

Repetitive Sequence (Multiple entries allowed)

• 21: Related Reference (mandatory) - Reference to related payment/transaction
• 32B: Currency and Amount (mandatory) - Currency code and amount to be credited
• 50: Ordering Customer (optional) - Customer initiating the payment
• 52: Ordering Institution (optional) - Institution initiating the payment
• 56: Intermediary Institution (optional) - Intermediary in payment chain

Network Validation Rules

• C2 Rule: Either field 50 (Ordering Customer) or field 52 (Ordering Institution) must be present, but not both
• Currency Consistency: All 32B fields should use consistent currency (when multiple sequences)
• Reference Format: Transaction and related references must follow SWIFT format rules
• Date Validation: Value date must be valid and properly formatted (YYMMDD)
• Amount Validation: All amounts must be positive and within acceptable ranges
• Institution Codes: BIC codes must be valid when institution fields are used

MT210Sequence Details

Each sequence within the message represents a separate payment notification and contains:

• Individual payment reference (field 21)
• Specific currency and amount (field 32B)
• Payment originator identification (either field 50 or 52)
• Optional intermediary institution details (field 56)

Processing Considerations

• Advance Notice: Typically sent before the actual payment message
• Reconciliation: Used for matching expected vs. actual payments
• Liquidity Planning: Enables receiving institution to plan cash positions
• Settlement Timing: Coordinates with payment system settlement cycles
• Exception Handling: Facilitates investigation of missing payments

SRG2025 Status

• No Structural Changes: MT210 format remains unchanged in SRG2025
• Enhanced Validation: Additional validation rules for payment notification accuracy
• Cross-Border Compliance: Enhanced validation for international payment notifications
• Settlement Integration: Improved integration with modern settlement systems

Integration Considerations

• Banking Systems: Compatible with liquidity management and treasury systems
• API Integration: RESTful API support for modern cash management platforms
• Processing Requirements: Supports real-time notification and cash flow planning
• Compliance Integration: Built-in validation for correspondent banking requirements

Relationship to Other Messages

• Triggers: Often precedes actual payment messages like MT202, MT103, or MT205
• Responses: May generate acknowledgment or status confirmation messages
• Related: Works with account reporting messages and settlement confirmations
• Alternatives: Direct payment messages for immediate transfer without pre-advice
• Status Updates: Enables reconciliation of expected vs. actual payments received

Fields

field_20: Field20

field_25: Option<Field25NoOption>

field_30: Field30

sequence: Vec<MT210Sequence>

Implementations

impl MT210

pub fn validate() -> &'static str

Get validation rules for this message type

Trait Implementations

impl Clone for MT210

fn clone(&self) -> MT210

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for MT210

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for MT210

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for MT210

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

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 MT210

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 MT210