Struct Field59A 

pub struct Field59A {
    pub account: Option<String>,
    pub bic: String,
}

Field 59A: Beneficiary Customer (Option A)

Purpose

Provides structured beneficiary customer identification using BIC-based format for optimal STP (Straight-Through Processing) compliance. This option combines optional account information with mandatory BIC identification, enabling automated processing and efficient routing through the correspondent banking network.

Format Specification

• Swift Format: [/34x]4!a2!a2!c[3!c]
• Account: Optional 34-character account identifier
• BIC Structure: 8 or 11 character Bank Identifier Code
• BIC Format: Bank Code (4) + Country (2) + Location (2) + Optional Branch (3)

Business Context Applications

• STP Processing: Optimal format for automated payment processing
• Correspondent Banking: Direct routing through BIC network
• High-volume Payments: Efficient processing for payment batches
• Standard Transfers: Most common format for routine payments

BIC Code Structure and Validation

8-Character BIC (Head Office)

• Bank Code: 4 alphabetic characters (institution identifier)
• Country Code: 2 alphabetic characters (ISO 3166-1 alpha-2)
• Location Code: 2 alphanumeric characters (city/region identifier)
• Usage: Default routing to institution’s head office

11-Character BIC (Branch Office)

• Branch Code: Additional 3 alphanumeric characters
• Branch Identification: Specific branch or department routing
• Usage: Direct routing to specific branch location
• Validation: Branch code must be valid for the institution

Account Information Guidelines

Account Format Options

• IBAN: International Bank Account Number (preferred for EUR and some currencies)
• Domestic Account: Country-specific account number format
• Special Identifiers: Institution-specific customer identifiers
• No Account: BIC-only identification for certain transaction types

Account Validation Requirements

• IBAN Validation: Checksum and format validation for IBAN accounts
• Domestic Standards: Compliance with local account number formats
• Character Set: Standard SWIFT character set restrictions
• Length Limits: Maximum 34 characters for account information

STP Processing Advantages

• Automated Routing: Direct BIC-based routing without manual intervention
• Validation Efficiency: Automated BIC verification and reachability checks
• Processing Speed: Fastest processing option for payment instructions
• Cost Effectiveness: Lower processing costs due to automation

Network Validation Requirements

• BIC Reachability: BIC must be active and reachable in SWIFT network
• BIC Format: Must conform to ISO 9362 standard
• Account Compatibility: Account format must be compatible with receiving institution
• Currency Support: Institution must support the payment currency

Regional Considerations

SEPA (Single Euro Payments Area)

• IBAN Requirement: IBAN mandatory for EUR payments within SEPA
• BIC Usage: BIC required for non-SEPA or high-value SEPA payments
• Processing Rules: SEPA-specific validation and routing rules

US Dollar Payments

• Fedwire: BIC required for USD payments via Fedwire
• CHIPS: BIC-based routing for CHIPS network payments
• Correspondent Banking: BIC enables correspondent banking relationships

Error Prevention Guidelines

• BIC Verification: Confirm BIC is active and supports required services
• Account Validation: Verify account format matches institution standards
• Currency Check: Ensure institution accepts the payment currency
• Reachability Test: Confirm institution is reachable for the message type

Usage Examples

// With IBAN account
:59A:/GB82WEST12345698765432
MIDLGB22XXX

// With domestic account number
:59A:/12345678
CHASUS33XXX

// BIC-only identification
:59A:DEUTDEFFXXX

Related Fields Integration

• Field 57A: Account with Institution (beneficiary bank BIC)
• Field 56A: Intermediary Institution (routing BIC)
• Field 70: Remittance Information (payment purpose)
• Field 33B: Currency/Amount (currency compatibility check)

Compliance Framework

• STP Standards: Full compliance with STP processing requirements
• BIC Directory: Compliance with SWIFT BIC directory standards
• Regulatory Requirements: Meeting regulatory identification standards
• Audit Trail: Complete electronic audit trail for automated processing

Processing Impact

• Routing Efficiency: Direct routing through correspondent banking network
• Processing Time: Fastest processing due to automated handling
• Cost Optimization: Lower fees due to STP processing
• Error Reduction: Reduced manual intervention and error rates

Best Practices

• BIC Accuracy: Always verify BIC codes before transmission
• Account Standards: Follow local account number conventions
• STP Optimization: Use this option for maximum processing efficiency
• Regular Updates: Keep BIC information current and validated

See Also

• Swift FIN User Handbook: Option A Beneficiary Specifications
• ISO 9362 Standard: BIC Code Structure and Validation
• STP Implementation Guide: Beneficiary Identification Best Practices

Fields

account: Option<String>

Account number (optional)

bic: String

BIC code

Trait Implementations

impl Clone for Field59A

fn clone(&self) -> Field59A

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for Field59A

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Field59A

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for Field59A

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

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 Field59A

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 Field59A