Struct Field28 

pub struct Field28 {
    pub statement_number: u32,
    pub sequence_number: Option<u8>,
}

Field 28: Statement Number / Sequence Number / Message Index

Purpose

Provides statement numbering, sequence identification, and message indexing capabilities for financial statements, batch operations, and multi-part message communication. This field enables proper ordering, continuation tracking, and completeness verification of related messages or statement sequences.

Format Variants

• Field 28: 5n[/2n] - Statement number with optional sequence
• Field 28C: 5n[/5n] - Statement number with extended sequence
• Field 28D: 5n/5n - Message index and total count

Presence

• Status: Mandatory in statement messages and batch operations
• Swift Error Codes: T40 (invalid number), T51 (format violation)
• Usage Context: Statement numbering and message sequencing

Usage Rules

• Sequential Numbering: Numbers must follow logical sequence for statements
• Index Validation: Message index must not exceed total count in Field 28D
• Completeness: Enables verification that all messages/statements received
• Ordering: Facilitates proper chronological ordering of related messages

Network Validation Rules

• Positive Numbers: All numeric values must be greater than zero
• Range Validation: Numbers must be within reasonable business limits
• Format Compliance: Must follow exact numeric format specifications
• Logic Validation: Index must not exceed total in indexed variants

Field Variants and Usage

Field 28 - Basic Statement/Sequence Number

• Format: 5n[/2n]
• Usage: Account statements with optional sequence numbers
• Statement Number: Primary identifier for statement period
• Sequence Number: Sub-sequence within statement period

Field 28C - Extended Statement/Sequence Number

• Format: 5n[/5n]
• Usage: Extended numbering for complex statement structures
• Enhanced Range: Larger sequence number capacity
• Complex Statements: Multi-part statements with extensive sequences

Field 28D - Message Index/Total

• Format: 5n/5n
• Usage: Batch message indexing for completeness verification
• Index Number: Current message position in sequence
• Total Count: Complete count of messages in batch
• Verification: Enables receiver to verify all messages received

Business Context

• Statement Management: Systematic numbering of account statements
• Batch Processing: Sequencing multiple related transactions
• Audit Trail: Maintaining proper sequence records for compliance
• Message Integrity: Ensuring complete message set delivery

Examples

:28:12345              // Statement 12345 (no sequence)
:28:12345/01           // Statement 12345, sequence 1
:28C:98765/00123       // Extended statement with sequence
:28D:001/010           // Message 1 of 10 total
:28D:010/010           // Final message (10 of 10)

Statement Sequencing Logic

• Daily Statements: Incremental numbering by business day
• Monthly Statements: Period-based numbering with daily sequences
• Special Statements: Ad-hoc numbering for specific requirements
• Continuation: Sequence numbers for multi-part statements

Batch Message Processing

• Transmission Order: Sequential transmission of indexed messages
• Completeness Check: Verification all messages received
• Error Recovery: Re-transmission of missing message indices
• Processing Logic: Ordered processing based on index sequence

Regional Considerations

• European Standards: SEPA statement numbering requirements
• US Banking: Federal Reserve statement sequence standards
• Asian Markets: Local statement numbering conventions
• International: Cross-border statement coordination

Error Prevention

• Number Validation: Verify numbers are positive and within range
• Sequence Logic: Ensure logical progression of sequence numbers
• Index Validation: Confirm message index does not exceed total
• Completeness Check: Verify all expected messages received

Related Fields

• Field 60: Opening Balance (statement start information)
• Field 62: Closing Balance (statement end information)
• Field 64: Closing Available Balance (additional statement data)
• Block Headers: Message timestamps and references

Processing Applications

• MT940: Customer Statement Message (Field 28)
• MT942: Interim Transaction Report (Field 28C)
• MT101: Request for Transfer (Field 28D)
• MT102: Multiple Customer Credit Transfer (Field 28D)

STP Compliance

• Automated Sequencing: System-generated sequence numbers for STP
• Integrity Validation: Automated completeness checking
• Exception Handling: Missing sequence detection and alerts
• Quality Control: Real-time sequence validation

Compliance and Audit

• Regulatory Reporting: Sequential statement reporting requirements
• Audit Trail: Maintaining complete sequence records
• Record Keeping: Statement number preservation for regulatory periods
• Investigation Support: Sequence-based transaction reconstruction

See Also

• Swift FIN User Handbook: Statement Numbering Standards
• MT940/942 Guidelines: Statement Sequence Requirements
• Batch Processing Standards: Message Indexing Specifications
• Regulatory Guidelines: Statement Numbering Compliance Field 28: Basic Statement Number/Sequence Number

Basic statement numbering with optional sequence for account statements and transaction reports.

Fields

statement_number: u32

Statement number

Format: 5n - Up to 5 digits (1-99999) Primary identifier for statement period or report

sequence_number: Option<u8>

Optional sequence number

Format: [/2n] - Optional 1-2 digits after slash (1-99) Used for multi-part statements within same period

Trait Implementations

impl Clone for Field28

fn clone(&self) -> Field28

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for Field28

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Field28

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for Field28

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

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

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl SwiftField for Field28

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

Parse field value from string representation

fn to_swift_string(&self) -> String

Convert field back to SWIFT string format

fn format_spec() -> &'static str

Get field format specification

fn parse_with_variant( value: &str, _variant: Option<&str>, _field_tag: Option<&str>, ) -> Result<Self>

where Self: Sized,

Parse field value with variant hint for enum fields Default implementation falls back to regular parse

fn valid_variants() -> Option<Vec<&'static str>>

Get valid variant letters for enum fields Returns None for non-enum fields, Some(vec) for enum fields

impl StructuralPartialEq for Field28