Struct MT299 

pub struct MT299 {
    pub field_20: Field20,
    pub field_21: Option<Field21NoOption>,
    pub field_79: Field79,
}

MT299: Free Format Message (Category 2 - Financial Institution Transfers)

Purpose

Used for free format communication between financial institutions regarding institutional transfers and treasury operations. Provides a flexible structure for various types of communication that don’t fit into other structured Category 2 message formats.

Scope

This message is:

• Sent between financial institutions for treasury and institutional transfer communications
• Used for inquiries, clarifications, and general information exchange about Category 2 operations
• Contains free format narrative text for flexible institutional communication
• Supports various treasury scenarios requiring custom messaging
• Essential for operational communications in correspondent banking

Key Features

• Free Format Content: Field 79 for flexible narrative text
• Treasury Context: Related to institutional transfers and treasury operations
• Bilateral Communication: Facilitates bank-to-bank operational communication
• Reference Tracking: Links to related institutional transfer messages or operations
• Flexible Structure: Minimal mandatory fields for maximum operational flexibility
• Operational Focus: Designed for treasury and institutional transfer operations

Common Use Cases

• Treasury operation inquiry messages
• Institutional transfer status update communications
• Settlement clarification requests
• Liquidity management communications
• Special instruction messages for institutional transfers
• Problem resolution communications for Category 2 operations
• Correspondent banking operational messages
• Cross-border institutional transfer clarifications
• Central bank communication messages
• Settlement system operational updates

Field Structure

• 20: Sender’s Reference (mandatory) - Message reference for this communication
• 21: Related Reference (optional) - Reference to related message/transaction/operation
• 79: Narrative (mandatory) - Free format text content for institutional communication

Treasury and Institutional Applications

Settlement Communications

• Real-time gross settlement (RTGS) operational messages
• Net settlement system communications
• Central bank settlement clarifications
• Cross-currency settlement coordination

Correspondent Banking

• Nostro/vostro account operational messages
• Credit line communications
• Account reconciliation inquiries
• Liquidity management discussions

Treasury Operations

• Foreign exchange settlement communications
• Money market operation messages
• Institutional funding communications
• Treasury position management messages

Network Validation Rules

• Narrative Format: If narrative starts with /REJT/ or /RETN/, must follow Payments Reject/Return Guidelines
• Reference Format: Transaction references must follow SWIFT formatting standards
• Content Guidelines: Free format content should be relevant to institutional transfers
• Professional Communication: Content should maintain institutional communication standards

Special Format Handling

Reject/Return Messages

When the narrative begins with /REJT/ or /RETN/, the message should follow specific guidelines:

• Structured format for payment exception handling
• Clear indication of reject/return reasons
• Reference to original institutional transfer
• Appropriate reason codes where applicable

Operational Messages

• Settlement system status updates
• Technical issue communications
• Operational procedure clarifications
• Emergency communication protocols

Processing Considerations

• Operational Priority: Often used for time-sensitive institutional communications
• Clarity Required: Free format content should be clear and unambiguous
• Follow-up: May require structured message responses
• Audit Trail: Maintains record of institutional operational communications
• Escalation Path: Part of operational issue resolution procedures

SRG2025 Status

• Structural Changes: None - MT299 format remains unchanged in SRG2025
• Validation Updates: Enhanced guidelines for institutional transfer communications
• Processing Improvements: Better integration with modern settlement systems
• Compliance Notes: Enhanced support for operational communication workflows

Integration Considerations

• Banking Systems: Compatible with treasury management and settlement communication systems
• API Integration: RESTful API support for modern institutional banking communication platforms
• Processing Requirements: Supports both automated and manual message generation for operational needs
• Compliance Integration: Built-in validation for regulatory institutional communication requirements

Relationship to Other Messages

• Triggers: Triggered by operational needs related to Category 2 institutional transfers
• Responses: May generate response messages or trigger follow-up operational actions
• Related: Works with all Category 2 messages (MT200-series) for supporting communication
• Alternatives: Structured messages for specific scenarios with defined communication formats
• Status Updates: Provides flexible operational updates for institutional transfer processes

Fields

field_20: Field20

field_21: Option<Field21NoOption>

field_79: Field79

Implementations

impl MT299

pub fn validate() -> &'static str

Get validation rules for this message type

Trait Implementations

impl Clone for MT299

fn clone(&self) -> MT299

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for MT299

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for MT299

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for MT299

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

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 MT299

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 MT299