Struct Field59A

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

Field 59: Beneficiary Customer

Overview

Field 59 identifies the beneficiary customer in SWIFT payment messages, representing the ultimate recipient of the payment funds. This field supports multiple identification options (59A, 59F, and 59 without letter) to accommodate different beneficiary types and identification requirements. The beneficiary customer is the final destination for payment funds and must be clearly identified for regulatory compliance and payment delivery.

Format Specification

Field 59A (BIC Option)

Format: [/account]BIC

• account: Optional account number (up to 34 characters)
• BIC: Bank Identifier Code (8 or 11 characters)

Field 59F (Party Identifier Option)

Format: party_identifier + 4*(1!n/33x)

• party_identifier: Up to 35 characters
• name_and_address: Up to 4 structured lines (format: n/text)

Field 59 (Basic Option)

Format: 4*35x

• beneficiary_customer: Up to 4 lines of 35 characters each

Structure

Option A (BIC):
/DE89370400440532013000
DEUTDEFFXXX

Option F (Party ID):
PARTYID123456789
1/JOHN DOE
2/123 MAIN STREET
3/NEW YORK NY 10001
4/UNITED STATES

Basic Option:
MUELLER GMBH
HAUPTSTRASSE 1
60311 FRANKFURT
GERMANY

Field Components

• Account Number: Beneficiary’s account identifier (Option A)
• BIC Code: Bank Identifier Code (Option A)
• Party Identifier: Structured party identification (Option F)
• Name and Address: Beneficiary details (Options F and Basic)
• Line Numbers: Structured addressing (Option F: 1-4)

Usage Context

Field 59 variants are used in:

• MT103: Single Customer Credit Transfer
• MT200: Financial Institution Transfer
• MT202: General Financial Institution Transfer
• MT202COV: Cover for customer credit transfer
• MT205: Financial Institution Transfer for its own account

Business Applications

• Payment delivery: Identifying final payment recipient
• Regulatory compliance: Meeting beneficiary identification requirements
• AML/KYC compliance: Supporting anti-money laundering checks
• Payment transparency: Providing clear beneficiary details
• Cross-border payments: International beneficiary identification
• Sanctions screening: Enabling compliance checks

Examples

:59A:/DE89370400440532013000
DEUTDEFFXXX
└─── German bank customer with IBAN and BIC

:59F:PARTYID123456789
1/JOHN DOE
2/123 MAIN STREET
3/NEW YORK NY 10001
4/UNITED STATES
└─── Structured party identification with address

:59:MUELLER GMBH
HAUPTSTRASSE 1
60311 FRANKFURT
GERMANY
└─── Basic beneficiary identification

Validation Rules

Option A (BIC)

1. BIC format: Must be valid 8 or 11 character BIC
2. Account number: Maximum 34 characters (optional)
3. Character validation: SWIFT character set compliance

Option F (Party Identifier)

1. Party identifier: Maximum 35 characters, required
2. Name/address lines: Maximum 4 lines, format n/text
3. Line content: Maximum 33 characters per line
4. Line numbers: Must be 1-4

Basic Option

1. Line count: Maximum 4 lines
2. Line length: Maximum 35 characters per line
3. Content: Must contain meaningful beneficiary information

Network Validated Rules (SWIFT Standards)

• BIC must be valid if used (Error: T10)
• Account number cannot exceed 34 characters (Error: T14)
• Party identifier cannot exceed 35 characters (Error: T50)
• Name/address lines cannot exceed specified limits (Error: T26)
• Must use SWIFT character set only (Error: T61)
• Beneficiary must be identifiable (Error: T51)
• Only one 59 option per message (Error: C59)

Fields

account: Option<String>

Account number (optional)

bic: BIC

BIC (Bank Identifier Code)

Implementations

impl Field59A

pub fn new( account: Option<String>, bic: impl Into<String>, ) -> Result<Self, ParseError>

Create a new Field59A with validation

pub fn account(&self) -> Option<&str>

Get the account number

pub fn bic(&self) -> &str

Get the 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 Display for Field59A

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

Formats the value using the given formatter.

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(content: &str) -> Result<Self, ParseError>

Parse field value from string representation

fn to_swift_string(&self) -> String

Convert field back to SWIFT string format

fn validate(&self) -> ValidationResult

Validate field according to SWIFT format rules

fn format_spec() -> &'static str

Get field format specification

impl Eq for Field59A

impl StructuralPartialEq for Field59A