Struct Field21NoOption 

pub struct Field21NoOption {
    pub reference: String,
}

Field 21: Related Reference / Transaction Reference

Purpose

Specifies a unique reference assigned by the sending financial institution to unambiguously identify the transaction or instruction. This field serves as a cross-reference to link related messages and facilitates transaction tracking across the payment chain.

Format

• Swift Format: 16x (NoOption), 35x (C, D, E options), 16x (F, R options)
• Description: Alphanumeric characters with specific length restrictions per option
• Character Set: Letters, digits, and limited special characters (excluding consecutive slashes)

Presence

• Status: Conditional/Optional depending on message type and sequence
• Swift Error Codes: T26 (invalid characters), T50 (format violation)
• Usage Context: Transaction identification and cross-referencing

Usage Rules

• Reference Uniqueness: Must be unique within the context of the sending institution
• Cross-Reference: Often used to link related instructions or provide trace information
• Slash Restrictions: Must not start or end with slash, no consecutive slashes allowed
• Transaction Chain: Enables tracking across multiple message exchanges

Network Validation Rules

• Character Validation: Only alphanumeric and specific special characters allowed
• Length Validation: Must not exceed maximum length for specific option
• Format Compliance: Must follow Swift character set standards
• Slash Rules: Proper slash usage for structured references

Field Options and Usage

NoOption (16x)

• Usage: Basic transaction reference in customer payments (MT103)
• Length: Up to 16 characters
• Purpose: Simple transaction identification

Option C (35x)

• Usage: Customer-specific references, often in treasury operations
• Length: Up to 35 characters
• Purpose: Extended reference capability for complex transactions

Option D (35x)

• Usage: Deal reference in treasury and money market transactions
• Length: Up to 35 characters
• Purpose: Transaction identification in financial markets

Option E (35x)

• Usage: Related reference for linked transactions
• Length: Up to 35 characters
• Purpose: Cross-referencing between related instructions

Option F (16x)

• Usage: File reference for batch operations (MT102)
• Length: Up to 16 characters
• Purpose: Batch identification and grouping

Option R (16x)

• Usage: Related file reference
• Length: Up to 16 characters
• Purpose: Linking to previously sent file references

Business Context

• Transaction Tracking: Essential for audit trails and payment investigation
• Reconciliation: Enables matching of instructions with confirmations
• STP Processing: Facilitates automated processing and exception handling
• Regulatory Compliance: Supports regulatory reporting and monitoring requirements

Examples

:21:CUST/20250719/001     // Customer payment reference
:21C:FX/USD/EUR/12345     // Treasury deal reference
:21D:SPOT20250719001      // Deal reference for spot transaction
:21E:REL/MT103/20250719   // Related transaction reference
:21F:BATCH001             // File reference for batch
:21R:RELBATCH001          // Related file reference

Regional Considerations

• European Payments: SEPA reference standards compliance
• US Payments: FedWire reference format considerations
• Asian Markets: Local reference numbering schemes
• Cross-Border: International reference coordination

Error Prevention

• Reference Validation: Verify uniqueness within institutional context
• Format Checking: Ensure compliance with character set restrictions
• Length Verification: Confirm reference length within option limits
• Slash Validation: Check proper slash usage and positioning

Related Fields

• Field 20: Sender’s Reference (primary transaction identifier)
• Field 11: MT Reference (message-level reference)
• Field 72: Sender to Receiver Information (additional reference details)
• Block Headers: Message references in application headers

Transaction Lifecycle

• Initiation: Original reference assignment by sending institution
• Processing: Reference propagation through payment chain
• Confirmation: Reference matching in return messages
• Settlement: Reference inclusion in settlement confirmations

STP Compliance

• Automated Processing: Reference format standardization for STP
• Exception Handling: Reference-based transaction investigation
• Matching Logic: Automated reference correlation across messages
• Quality Control: Reference validation in STP gateways

Compliance and Audit

• Audit Trail: Comprehensive transaction reference tracking
• Regulatory Reporting: Reference inclusion in compliance reports
• Investigation Support: Reference-based transaction reconstruction
• Documentation: Reference preservation for regulatory periods

See Also

• Swift FIN User Handbook: Reference Field Standards

• MT Message Reference Guide: Field 21 Specifications

• STP Guidelines: Reference Format Requirements

• Payment Processing Standards: Transaction Identification

  Field 21 NoOption: Basic Transaction Reference

Basic transaction reference used in customer payment instructions. Limited to 16 characters for simple transaction identification.

Fields

reference: String

Transaction reference (up to 16 characters)

Format: 16x - Alphanumeric with Swift character set restrictions Must not start/end with slash or contain consecutive slashes

Trait Implementations

impl Clone for Field21NoOption

fn clone(&self) -> Field21NoOption

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for Field21NoOption

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Field21NoOption

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for Field21NoOption

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

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 Field21NoOption

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 Field21NoOption