Struct Field23 

pub struct Field23 {
    pub function_code: String,
    pub days: Option<u8>,
    pub reference: String,
}

Field 23: Further Identification

Purpose

Provides additional identification information for financial transactions, particularly in money market and deposit transactions. This field enables precise categorization of transaction types, timing specifications, and reference information essential for proper transaction processing and regulatory compliance.

Format Specification

• Swift Format: 3!a[2!n]11x
• Structure: Function code + optional days + reference information
• Total Length: Maximum 16 characters
• Components: Mandatory function code, conditional days, mandatory reference

Business Context Applications

• Money Market Transactions: Deposit and call money operations
• Treasury Operations: Interest rate and liquidity management
• Corporate Banking: Commercial account management
• Settlement Processing: Transaction categorization and routing

Function Code Categories

Deposit Operations

• DEPOSIT: Standard deposit transactions
• NOTICE: Notice deposit with specific day requirements
• CALL: Call money transactions (immediate settlement)
• CURRENT: Current account operations

Commercial Operations

• COMMERCIAL: Commercial transaction identification
• BASE: Base rate reference transactions
• PRIME: Prime rate related operations

Network Validation Requirements

• Function Code: Must be valid 3-character alphabetic code
• Days Field: Only required/allowed for NOTICE function code
• Days Range: 1-99 days when specified for NOTICE transactions
• Reference Format: Must comply with 11x character set restrictions
• Character Set: Standard SWIFT character set compliance

Message Type Integration

• MT 200: Financial institution transfer (function classification)
• MT 202: General financial institution transfer (operation type)
• MT 210: Notice to receive (notice period specification)
• Treasury Messages: Various treasury operations requiring identification

Regional Considerations

• Money Market Standards: Regional money market convention compliance
• Central Bank Requirements: Regulatory classification requirements
• Settlement Systems: Local settlement system integration
• Regulatory Reporting: Transaction classification for reporting purposes

Validation Logic

Function Code Rules

• NOTICE: Requires days field (2!n format, 1-99)
• Other Codes: Days field must not be present
• Reference: Always required, 11x format compliance
• Character Validation: Uppercase alphabetic characters only

Processing Impact

• Settlement Timing: Function code affects settlement procedures
• Interest Calculation: Impacts interest computation methods
• Regulatory Classification: Determines reporting categories
• Risk Assessment: Influences risk management procedures

Error Prevention Guidelines

• Function Code Verification: Confirm valid function code selection
• Days Field Logic: Only include days for NOTICE transactions
• Reference Accuracy: Ensure reference information is correct
• Format Compliance: Verify character set and length requirements

Related Fields Integration

• Field 20: Transaction Reference (transaction context)
• Field 30: Value Date (timing coordination)
• Field 32A: Currency/Amount (transaction details)
• Field 52A/D: Ordering Institution (institutional context)

Compliance Framework

• Money Market Regulations: Compliance with money market standards
• Central Bank Reporting: Regulatory classification requirements
• Audit Documentation: Complete transaction categorization
• Risk Management: Transaction type classification for risk assessment

Best Practices

• Accurate Classification: Select appropriate function code
• Notice Period Management: Proper days specification for NOTICE
• Reference Standards: Consistent reference information format
• Documentation: Complete transaction categorization documentation

See Also

• Swift FIN User Handbook: Further Identification Field Specifications
• Money Market Standards: Function Code Classifications
• Treasury Operations Guide: Transaction Identification Best Practices

Fields

function_code: String

Function code (3!a format: BASE, CALL, COMMERCIAL, CURRENT, DEPOSIT, NOTICE, PRIME)

days: Option<u8>

Number of days (2!n format, optional, only for NOTICE function)

reference: String

Reference information (11x format)

Trait Implementations

impl Clone for Field23

fn clone(&self) -> Field23

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for Field23

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Field23

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for Field23

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

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 Field23

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 Field23