Field57A

Struct Field57A 

Source
pub struct Field57A {
    pub party_identifier: Option<String>,
    pub bic: String,
}
Expand description

Field 57: Account With Institution

§Purpose

Specifies the financial institution that services the account for the beneficiary customer (Field 59A). This field identifies the beneficiary’s bank where the account is maintained and where funds will ultimately be credited. Essential for final delivery of funds and beneficiary account identification. Critical component of payment settlement chain.

§Format Options Overview

  • Option A: BIC with optional party identifier - structured beneficiary bank identification
  • Option B: Party identifier with location - domestic beneficiary bank routing
  • Option C: Party identifier only - simplified beneficiary bank reference
  • Option D: Party identifier with name/address - detailed beneficiary bank information

§Business Context Applications

  • Beneficiary Bank: Institution maintaining beneficiary’s account
  • Final Settlement: Ultimate destination for payment funds
  • Account Services: Institution providing account services to beneficiary
  • Regulatory Reporting: Required for beneficiary institution identification

§Usage Rules and Conditions

  • Conditional Presence: Required based on Rules C5 and C10
  • Receiver Default: When absent, Receiver is also the account with institution
  • IBAN Compatibility: Applicable even when Field 59A contains IBAN
  • Direct Settlement: Enables direct settlement when Receiver is account institution

§Special Payment Method Codes

§Critical Settlement Instructions

  • //FW: Fedwire routing - Required by US banks for Fedwire settlement
  • //RT: Real-Time Gross Settlement - Binding instruction for RTGS systems
  • //AU: Australian payment system settlement
  • //IN: Indian payment system settlement

§Code Usage Rules

  • Single Usage: Codes //FW, //AU, //IN, //RT should appear only once in Field 56A or 57A
  • Binding Nature: //RT code is binding and cannot be followed by other information
  • Final Settlement: Ensures proper final settlement through appropriate systems
  • System Integration: Enables automated settlement in national payment systems

§Network Validation Requirements

  • BIC Registration: All BIC codes must be registered financial institutions
  • Account Services: Institution must provide account services to beneficiaries
  • Settlement Capability: Must support final settlement in transaction currency
  • Regulatory Compliance: Must meet beneficiary institution requirements

§Settlement Logic and Processing

§Direct Settlement

  • Receiver as Account Institution: Simplest settlement scenario
  • Direct Relationship: When Sender has direct relationship with beneficiary bank
  • Bilateral Agreements: Pre-established settlement arrangements
  • Currency Considerations: Direct settlement in transaction currency

§Intermediated Settlement

  • Through Intermediary: Settlement via Field 56A intermediary
  • Correspondent Network: Utilizing correspondent banking relationships
  • Multi-Hop Settlement: Complex settlement chains with multiple institutions
  • Optimization: Most efficient settlement path selection

§Regional Payment System Integration

§North American Systems

  • Fedwire (//FW): US Federal Reserve final settlement system
  • ACH Networks: Automated clearing house final settlement
  • Canadian Systems: Canadian payment system final settlement

§European Systems

  • TARGET2: European Central Bank RTGS final settlement
  • SEPA: Single Euro Payments Area account crediting
  • National Systems: Country-specific final settlement systems

§Asia-Pacific Systems

  • Australian (//AU): Australian payment system final settlement
  • Indian (//IN): Indian payment system final settlement
  • Regional Networks: ASEAN and other regional final settlement

§Beneficiary Protection and Compliance

  • Account Verification: Ensuring beneficiary account exists and is operational
  • Name Matching: Coordination with beneficiary customer name in Field 59A
  • Regulatory Requirements: Meeting beneficiary institution reporting requirements
  • Sanctions Screening: Beneficiary institution sanctions compliance

§STP Processing Benefits

  • Automated Settlement: System-driven final settlement based on clear identification
  • Account Integration: Direct integration with beneficiary account systems
  • Exception Reduction: Proper institution identification reduces settlement failures
  • Straight-Through Processing: Enhanced STP through structured settlement data

§Error Prevention Guidelines

  • Institution Verification: Confirm institution provides account services
  • Account Relationship: Verify institution-beneficiary account relationship
  • System Compatibility: Ensure institution supports required settlement systems
  • Currency Support: Confirm institution handles transaction currency
  • Field 59A: Beneficiary Customer (account holder identification)
  • Field 56A: Intermediary (settlement routing)
  • Field 32A: Value Date, Currency, Amount (settlement details)
  • Field 70: Remittance Information (payment purpose)

§Compliance Framework

  • Beneficiary Institution Due Diligence: Enhanced due diligence requirements
  • Account Verification: Regulatory account verification requirements
  • Settlement Documentation: Complete settlement chain documentation
  • Audit Trail: Comprehensive beneficiary institution audit trail

§Performance and Risk Management

  • Settlement Speed: Optimized settlement speed through proper institution identification
  • Settlement Risk: Risk mitigation through established institution relationships
  • Operational Risk: Backup settlement arrangements for business continuity
  • Cost Optimization: Efficient settlement cost management

§See Also

  • Swift FIN User Handbook: Account With Institution Specifications

  • Payment Settlement Guidelines: Beneficiary Institution Requirements

  • Cross-Border Payments: Final Settlement Standards

  • Regulatory Compliance: Beneficiary Institution Due Diligence

    Field 57A: Account With Institution (BIC with Party Identifier)

Structured beneficiary bank identification using BIC code with optional party identifier. Preferred option for automated settlement and final fund delivery.

Fields§

§party_identifier: Option<String>

Optional party identifier for settlement and payment method codes

Format: [/1!a][/34x] - Single character code + up to 34 character identifier May contain special codes: //FW (Fedwire), //RT (RTGS), //AU (Australian), //IN (Indian)

§bic: String

Bank Identifier Code of the account with institution

Format: 4!a2!a2!c[3!c] - 8 or 11 character BIC code Must be registered financial institution providing account services

Trait Implementations§

Source§

impl Clone for Field57A

Source§

fn clone(&self) -> Field57A

Returns a duplicate of the value. Read more
1.0.0 · Source§

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

Performs copy-assignment from source. Read more
Source§

impl Debug for Field57A

Source§

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

Formats the value using the given formatter. Read more
Source§

impl<'de> Deserialize<'de> for Field57A

Source§

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>
where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer. Read more
Source§

impl PartialEq for Field57A

Source§

fn eq(&self, other: &Field57A) -> bool

Tests for self and other values to be equal, and is used by ==.
1.0.0 · Source§

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.
Source§

impl Serialize for Field57A

Source§

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>
where __S: Serializer,

Serialize this value into the given Serde serializer. Read more
Source§

impl SwiftField for Field57A

Source§

fn parse(value: &str) -> Result<Self>

Parse field value from string representation
Source§

fn to_swift_string(&self) -> String

Convert field back to SWIFT string format
Source§

fn format_spec() -> &'static str

Get field format specification
Source§

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
Source§

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
Source§

impl StructuralPartialEq for Field57A

Auto Trait Implementations§

Blanket Implementations§

Source§

impl<T> Any for T
where T: 'static + ?Sized,

Source§

fn type_id(&self) -> TypeId

Gets the TypeId of self. Read more
Source§

impl<T> Borrow<T> for T
where T: ?Sized,

Source§

fn borrow(&self) -> &T

Immutably borrows from an owned value. Read more
Source§

impl<T> BorrowMut<T> for T
where T: ?Sized,

Source§

fn borrow_mut(&mut self) -> &mut T

Mutably borrows from an owned value. Read more
Source§

impl<T> CloneToUninit for T
where T: Clone,

Source§

unsafe fn clone_to_uninit(&self, dest: *mut u8)

🔬This is a nightly-only experimental API. (clone_to_uninit)
Performs copy-assignment from self to dest. Read more
Source§

impl<T> Fake for T

Source§

fn fake<U>(&self) -> U
where Self: FakeBase<U>,

Source§

fn fake_with_rng<U, R>(&self, rng: &mut R) -> U
where R: Rng + ?Sized, Self: FakeBase<U>,

Source§

impl<T> From<T> for T

Source§

fn from(t: T) -> T

Returns the argument unchanged.

Source§

impl<T, U> Into<U> for T
where U: From<T>,

Source§

fn into(self) -> U

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

Source§

impl<T> IntoEither for T

Source§

fn into_either(self, into_left: bool) -> Either<Self, Self>

Converts self into a Left variant of Either<Self, Self> if into_left is true. Converts self into a Right variant of Either<Self, Self> otherwise. Read more
Source§

fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
where F: FnOnce(&Self) -> bool,

Converts self into a Left variant of Either<Self, Self> if into_left(&self) returns true. Converts self into a Right variant of Either<Self, Self> otherwise. Read more
Source§

impl<T> Same for T

Source§

type Output = T

Should always be Self
Source§

impl<T> ToOwned for T
where T: Clone,

Source§

type Owned = T

The resulting type after obtaining ownership.
Source§

fn to_owned(&self) -> T

Creates owned data from borrowed data, usually by cloning. Read more
Source§

fn clone_into(&self, target: &mut T)

Uses borrowed data to replace owned data, usually by cloning. Read more
Source§

impl<T, U> TryFrom<U> for T
where U: Into<T>,

Source§

type Error = Infallible

The type returned in the event of a conversion error.
Source§

fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>

Performs the conversion.
Source§

impl<T, U> TryInto<U> for T
where U: TryFrom<T>,

Source§

type Error = <U as TryFrom<T>>::Error

The type returned in the event of a conversion error.
Source§

fn try_into(self) -> Result<U, <U as TryFrom<T>>::Error>

Performs the conversion.
Source§

impl<V, T> VZip<V> for T
where V: MultiLane<T>,

Source§

fn vzip(self) -> V

Source§

impl<T> DeserializeOwned for T
where T: for<'de> Deserialize<'de>,