Struct Field59F 

pub struct Field59F {
    pub party_identifier: Option<String>,
    pub name_and_address: Vec<String>,
}

Field 59F: Beneficiary Customer (Option F)

Purpose

Provides detailed beneficiary customer identification using party identifier combined with structured name and address information. This option enables comprehensive beneficiary documentation while maintaining STP compatibility through structured format requirements and enhanced customer identification capabilities.

Format Specification

• Swift Format: [/34x]4*(1!n/33x)
• Party Identifier: Optional 34-character identifier (account, reference, or ID)
• Name/Address Lines: Up to 4 lines with line number + 33 characters each
• Line Structure: Each line starts with line number (1-4) followed by content

Business Context Applications

• Enhanced KYC: Detailed customer identification for compliance
• Corporate Beneficiaries: Complex corporate structure identification
• Multi-jurisdictional: Cross-border regulatory compliance support
• High-value Transactions: Enhanced due diligence requirements

Party Identifier Usage

Identification Types

• Account Numbers: IBAN, domestic account numbers, or special identifiers
• Customer References: Internal bank customer reference numbers
• Government IDs: Tax identification numbers or business registration numbers
• Special Codes: Regulatory or industry-specific identification codes

Structured Name and Address Format

Line Number Requirements

• Line 1: Primary beneficiary name (mandatory)
• Line 2: Secondary name or business unit (optional)
• Line 3: Street address or PO Box (recommended)
• Line 4: City, postal code, country (recommended)

Content Guidelines

• Character Limit: 33 characters per line (excluding line number)
• Character Set: Standard SWIFT character set compliance
• Address Completeness: Sufficient detail for payment delivery
• Name Accuracy: Legal name matching official documentation

STP Processing Advantages

• Structured Format: Consistent field parsing and validation
• Line Numbering: Automated address field mapping
• Regulatory Compliance: Enhanced compliance documentation
• Data Quality: Improved accuracy through structured input

Network Validation Requirements

• Line Number Validation: Must use consecutive numbers 1-4
• Character Set Compliance: Standard SWIFT character restrictions
• Address Sufficiency: Adequate address detail for delivery
• Name Consistency: Consistent beneficiary name across lines

Regional Considerations

• Address Standards: Local address format compliance
• Regulatory Requirements: Enhanced beneficiary documentation
• Language Requirements: English language for international payments
• Cultural Sensitivity: Appropriate name and address formatting

Enhanced Due Diligence Support

Compliance Benefits

• Detailed Records: Comprehensive beneficiary documentation
• Audit Trail: Complete identification information
• Risk Assessment: Enhanced risk profiling capabilities
• Regulatory Reporting: Structured data for compliance reporting

Error Prevention Guidelines

• Complete Information: Provide all available identification details
• Accurate Line Numbering: Use correct sequential line numbers
• Character Compliance: Verify SWIFT character set usage
• Address Verification: Confirm address accuracy and completeness

Usage Examples

:59F:/GB82WEST12345698765432
1/ACME CORPORATION LIMITED
2/INTERNATIONAL TRADE DIVISION
3/123 BUSINESS PARK AVENUE
4/LONDON EC1A 1BB UNITED KINGDOM

Related Fields Integration

• Field 57A: Account with Institution (beneficiary bank)
• Field 70: Remittance Information (payment purpose)
• Field 77T: Structured Remittance Information (enhanced details)
• Field 72: Sender to Receiver Information (additional context)

Compliance Framework

• KYC Enhancement: Detailed customer identification support
• AML Compliance: Enhanced anti-money laundering documentation
• Regulatory Documentation: Complete beneficiary record keeping
• Audit Support: Comprehensive identification audit trail

Best Practices

• Complete Documentation: Provide all available beneficiary details
• Structured Approach: Use consistent line numbering and formatting
• Accuracy Verification: Verify all identification information
• Compliance Awareness: Understand regulatory documentation requirements

See Also

• Swift FIN User Handbook: Option F Beneficiary Specifications
• KYC Guidelines: Enhanced Customer Identification Requirements
• Regulatory Compliance: Beneficiary Documentation Standards

Fields

party_identifier: Option<String>

Party identifier

name_and_address: Vec<String>

Name and address lines

Trait Implementations

impl Clone for Field59F

fn clone(&self) -> Field59F

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for Field59F

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Field59F

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for Field59F

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

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 Field59F

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 Field59F