Struct ApplicationHeader 

pub struct ApplicationHeader {
    pub direction: String,
    pub message_type: String,
    pub destination_address: String,
    pub receiver_bic: String,
    pub priority: String,
    pub delivery_monitoring: Option<String>,
    pub obsolescence_period: Option<String>,
}

Application Header (Block 2): Message Type and Routing Information

Purpose

The Application Header provides essential message type identification and routing information, enabling the SWIFT network to properly categorize, prioritize, and deliver messages. This header determines processing rules, delivery monitoring, and time-critical handling requirements for financial messages.

Format Specification

• Input Format: {2:I103DDDDDDDDDDDDP[M][OOO]}
• Output Format: {2:O103HHMMDDDDDDDDDDDDYYYYMMDDHHMMNNNNNN}
• Direction Dependent: Structure varies for input (I) vs output (O)
• Variable Length: 18-21 characters for input, fixed for output

Business Context Applications

• Message Classification: Determines processing rules by message type
• Priority Handling: Urgent vs normal message processing
• Delivery Assurance: Monitoring and non-delivery notifications
• Time Management: Obsolescence period for time-sensitive messages

Direction Indicator

Input Messages (I)

• Sender Perspective: Messages being sent to SWIFT
• Validation: Full message validation applied
• Routing: To destination specified in header
• Storage: Stored in sender’s message archive

Output Messages (O)

• Receiver Perspective: Messages delivered from SWIFT
• Delivery: Includes delivery timestamp and MIR
• Status: Confirmed successful delivery
• Archive: Stored in receiver’s message archive

Message Type Classification

Category 1: Customer Payments (MT 1nn)

• MT 103: Single Customer Credit Transfer
• MT 110: Advice of Cheque
• Priority: Often urgent for same-day value

Category 2: Bank Transfers (MT 2nn)

• MT 202: General Financial Institution Transfer
• MT 202COV: Cover Payment
• Priority: High priority for bank liquidity

Category 9: Balance and Status (MT 9nn)

• MT 940: Customer Statement
• MT 950: Statement Message
• Priority: Normal, end-of-day processing

Priority Management

Urgent Priority (U)

• Processing: Immediate, ahead of normal messages
• Use Cases: Time-critical payments, cut-off deadlines
• Delivery: Fastest available route
• Cost: Premium pricing may apply

Normal Priority (N)

• Processing: Standard queue processing
• Use Cases: Regular payments and messages
• Delivery: Standard delivery timeframes
• Cost: Standard message pricing

System Priority (S)

• Processing: System-generated messages
• Use Cases: ACKs, NAKs, system notifications
• Delivery: Highest priority delivery
• Access: Reserved for SWIFT system use

Delivery Monitoring Options

Non-Delivery Warning (1)

• Timeout: Warning if not delivered within set time
• Action: Sender notified of delivery delay
• Use Case: Important but not critical messages

Delivery Notification (3)

• Confirmation: Positive delivery confirmation required
• Notification: MT 011 sent upon successful delivery
• Use Case: Critical messages requiring confirmation

No Monitoring (blank)

• Standard: Default delivery without monitoring
• Notification: No delivery status updates
• Use Case: Routine, non-critical messages

Obsolescence Period

• Format: 3 numeric digits (003-999)
• Unit: 5-minute intervals
• Maximum: 999 = 83 hours
• Purpose: Message validity timeout
• Action: Automatic cancellation if not delivered

Network Validation Requirements

• BIC Validation: Destination must be valid SWIFT participant
• Message Type: Must be valid for sender’s subscription
• Priority Rules: Certain messages restricted to normal priority
• Monitoring Compatibility: Not all messages support monitoring

Regional Considerations

• Cut-off Times: Regional deadlines for urgent messages
• Processing Windows: Regional operating hours impact
• Holiday Handling: Regional holidays affect delivery
• Regulatory Priority: Some regions mandate priority levels

Error Prevention Guidelines

• BIC Verification: Confirm destination BIC is reachable
• Type Validation: Ensure message type is authorized
• Priority Selection: Use appropriate priority level
• Monitoring Choice: Select monitoring based on criticality

Integration with Other Blocks

• Block 1: Sender identification coordination
• Block 3: Service options based on message type
• Block 4: Content validation per message type
• Block 5: Delivery confirmations and status

Compliance Framework

• Message Standards: Type-specific validation rules
• Priority Policies: Fair use of urgent priority
• Delivery SLAs: Service level compliance
• Audit Trail: Complete routing documentation

Processing Impact

• Queue Position: Priority determines processing order
• Validation Depth: Message type determines checks
• Routing Path: Optimal path based on priority
• Cost Calculation: Priority affects message pricing

Best Practices

• Priority Discipline: Reserve urgent for true urgency
• Monitoring Selection: Match monitoring to risk level
• Type Accuracy: Ensure correct message type selection
• Destination Validation: Verify BIC before sending

See Also

• SWIFT FIN User Handbook: Block 2 Specifications
• Message Type Catalog: Complete MT Message List
• Priority Guidelines: Best Practices for Priority Selection
• Delivery Monitoring: Service Options and Usage

Fields

direction: String

Message direction indicator

Format: 1!a - Single alphabetic character Values: I (Input to SWIFT), O (Output from SWIFT) Determines message format and processing perspective

message_type: String

Message type

Format: 3!n - Three numeric digits Examples: 103 (Customer Transfer), 202 (Bank Transfer), 940 (Statement) Determines validation rules and processing requirements

destination_address: String

Destination address

Format: 12!c - 12 alphanumeric characters
Structure: 8-char BIC + 1-char terminal + 3-char branch Identifies the receiving terminal in SWIFT network

receiver_bic: String

Receiver BIC extracted from destination address

Format: 8!c - First 8 characters of destination The receiving institution’s Bank Identifier Code

priority: String

Message priority

Format: 1!a - Single alphabetic character Values: U (Urgent), N (Normal), S (System) Determines processing priority and delivery speed

delivery_monitoring: Option<String>

Delivery monitoring option

Format: 1!n - Single numeric digit (optional) Values: 1 (Non-delivery warning), 3 (Delivery notification) Specifies delivery confirmation requirements

obsolescence_period: Option<String>

Obsolescence period

Format: 3!n - Three numeric digits (optional) Range: 003-999 (units of 5 minutes) Message validity timeout for automatic cancellation

Implementations

impl ApplicationHeader

pub fn parse(block2: &str) -> Result<Self>

Parse application header from block 2 string

Trait Implementations

impl Clone for ApplicationHeader

fn clone(&self) -> ApplicationHeader

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for ApplicationHeader

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for ApplicationHeader

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Display for ApplicationHeader

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

Formats the value using the given formatter.

impl PartialEq for ApplicationHeader

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

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for ApplicationHeader