Struct Field61 

pub struct Field61 {
    pub value_date: NaiveDate,
    pub entry_date: Option<String>,
    pub debit_credit_mark: String,
    pub funds_code: Option<char>,
    pub amount: f64,
    pub transaction_type: String,
    pub customer_reference: String,
    pub bank_reference: Option<String>,
    pub supplementary_details: Option<String>,
}

Field 61: Statement Line

Purpose

Represents individual transaction entries in customer statement messages (MT 940), providing detailed information about each debit or credit transaction affecting the account balance. This field is fundamental to statement processing, enabling detailed transaction tracking, reconciliation, and audit trail maintenance.

Format Specification

• Swift Format: 6!n[4!n]2a[1!a]15d1!a3!c[16x][//16x][34x]
• Complex Structure: Multiple components with optional elements
• Variable Length: Components can be present or absent based on transaction type
• Structured Data: Each component serves specific business purpose

Business Context Applications

• Customer Statements: Core component of MT 940 Customer Statement Message
• Transaction Detail: Complete transaction information for account holders
• Reconciliation: Detailed transaction data for account reconciliation
• Audit Trail: Complete transaction history for compliance and audit

Component Structure

Mandatory Components

• Value Date: Date when transaction affects account balance
• Debit/Credit Mark: Transaction direction (debit/credit)
• Amount: Transaction amount in account currency
• Transaction Type: Classification of transaction type

Optional Components

• Entry Date: Date transaction was posted (if different from value date)
• Funds Code: Availability of funds (immediate/float)
• Customer Reference: Transaction reference for customer
• Bank Reference: Bank’s internal transaction reference
• Supplementary Details: Additional transaction information

Network Validation Requirements

• Date Validation: Value date must be valid calendar date
• Amount Format: Decimal amount with proper precision
• Reference Format: References must follow specified format rules
• Transaction Code: Must be valid transaction type code
• Character Set: All components must use valid character sets

Transaction Processing

Balance Impact

• Debit Transactions: Reduce account balance (payments, charges, withdrawals)
• Credit Transactions: Increase account balance (deposits, transfers, interest)
• Reversal Transactions: Correct previous transaction errors
• Adjustment Transactions: Administrative balance adjustments

Transaction Types

• Customer Transfers: Payments and receipts
• Bank Services: Fees, charges, and service transactions
• Interest: Interest credits and debits
• Foreign Exchange: Currency conversion transactions

Regional Considerations

• European Banking: SEPA transaction processing and reporting
• US Banking: ACH, wire transfer, and check processing
• Asian Markets: Local payment system integration
• Cross-Border: International transaction processing

Error Prevention Guidelines

• Date Consistency: Verify dates are logical and within statement period
• Amount Verification: Confirm amount format and precision
• Reference Validation: Ensure references follow format requirements
• Balance Verification: Confirm transactions sum to balance changes

Related Fields Integration

• Field 60: Opening Balance (starting position)
• Field 62: Closing Balance (ending position after transactions)
• Field 64: Closing Available Balance (availability impact)
• Field 86: Information to Account Owner (additional details)

Compliance Framework

• Banking Regulations: Transaction reporting requirements
• Audit Standards: Complete transaction documentation
• Customer Rights: Detailed transaction information provision
• Data Retention: Transaction history retention requirements

See Also

• Swift FIN User Handbook: Statement Line Specifications
• MT 940 Message Standards: Customer Statement Processing
• Transaction Processing: Banking Transaction Standards
• Account Statement Requirements: Regional Banking Regulations

Fields

value_date: NaiveDate

Value date (6!n format, YYMMDD)

entry_date: Option<String>

Optional entry date (4!n format, MMDD)

debit_credit_mark: String

Debit/Credit mark (2a format: D, C, RD, RC)

funds_code: Option<char>

Optional funds code (1!a format)

amount: f64

Amount (15d format)

transaction_type: String

Transaction type identification code (4!a format)

customer_reference: String

Customer reference (2!a format)

bank_reference: Option<String>

Bank reference (16x format, preceded by //)

supplementary_details: Option<String>

Optional supplementary details (34x format)

Trait Implementations

impl Clone for Field61

fn clone(&self) -> Field61

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for Field61

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Field61

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for Field61

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

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 Field61

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 Field61