MT700 Field 57 — Advise Through Bank: Common Errors, Discrepancies, and Systemic Resolution

Introduction

Field 57 of the SWIFT MT700 Message (Advice Through Bank) operates as a routing instruction, not a substantive term of the credit. The illusion is that any bank name or SWIFT BIC code placed here simply directs the advice downstream. The failure mode emerges when practitioners conflate Field 57 with Field 58 (Nominated Bank), when they populate it with entities不具备 capacity to advise, or when the data in Field 57 mutates the operative availability of the credit in ways that violate UCP 600's strict undertaking architecture. A single erroneous BIC code in Field 57 can truncate the entire advising chain, isolate the beneficiary from notification, and trigger a systemic cascade of discrepancies that no amount of document preparation can remedy.

This guide isolates the three dominant failure modes, maps each to the operative language of UCP 600 and ISBP 745 (International Standard Banking Practice, Publication 745), and compiles a deterministic resolution architecture that eliminates ambiguity.

Failure Mode Analysis

Failure Mode 1: BIC Code Substitution — Field 57 vs. Field 58 Conflation

The most systemic error in MT700 construction is the placement of the nominated bank's BIC code into Field 57 instead of Field 58. Field 57 (Advise Through Bank) routes the advice; Field 58 (Nominated Bank) determines where the credit is available for presentation and negotiation.

When Field 57 and Field 58 contain the same BIC code, the issuing bank has inadvertently instructed the advising chain to treat a nominated bank as merely a conduit. This isolates the nominated bank's authority to honour or negotiate. The beneficiary, receiving the credit through Field 57's bank, may present documents to a bank that has no obligation under the credit because its role was never properly nominated under Article 12.

Diagnostic indicator: If Field 57 and Field 58 are identical, the credit's availability architecture is compromised. The nominated bank must appear only in Field 58.

Failure Mode 2: Advising Through a Non-Participant

Field 57 references a bank that is not a SWIFT participant, has no correspondent relationship with the issuing bank, or lacks the operational capacity to receive and transmit SWIFT messages. Under UCP 600 Article 9(b), the advising bank must satisfy itself as to apparent authenticity. A bank without SWIFT connectivity cannot authenticate the message.

This failure mode truncates the advisory chain. The issuing bank transmits the MT700; SWIFT routes it to Field 57's bank; that bank cannot authenticate or advise; the beneficiary is never notified. The credit exists as an operative instrument that no party can access.

Diagnostic indicator: Verify that the BIC code in Field 57 corresponds to a bank with active SWIFT connectivity and an established advising capability. Cross-reference against the SWIFT BIC directory.

Failure Mode 3: Empty or Malformed Field 57 Data

An empty Field 57 is permissible when the credit is to be advised directly by the issuing bank or when Field 52A (Issuing Bank's Identification) serves as the advising entity. However, when Field 57 contains partial data — a bank name without a BIC code, a city reference without an institution identifier, or a branch code referencing a non-existent office — the credit mutates into an ambiguous state.

UCP 600 Article 3(b) states: "A credit is irrevocable even if there is no indication to that effect." The irrevocability persists regardless of whether the Field 57 data is complete. But the practical effect is a credit that cannot be transmitted through SWIFT's automated routing, requiring manual intervention that introduces delay, cost, and the potential for human error.

Diagnostic indicator: Field 57 must contain either a complete BIC code (8 or 11 characters) or a structured combination of bank name, branch, city, and country that SWIFT's format validation accepts. Partial or free-text entries in Field 57 violate SWIFT message standards and will be rejected by the network.

Deterministic Resolution Architecture

Resolution 1 — Pre-Transmission Validation Protocol

Before transmitting the MT700, the issuing bank must compile a Field 57 compliance check:

• (a) Verify the BIC code in Field 57 is active and valid in the SWIFT BIC directory.
• (b) Confirm the Field 57 bank is distinct from the Field 58 bank (nominated bank). If they are identical, remove Field 57 and let Field 58 serve dual purpose, or route through Field 56 (Intermediary Bank) if a separate intermediary is intended.
• (c) If Field 57 is left empty, confirm that the credit will be advised directly through the issuing bank's own advising channel or through the nominated bank specified in Field 58.

Resolution 2 — Receiving Bank Triage

When a bank receives an MT700 in which it appears in Field 57 but lacks the capacity to advise:

• (a) The bank must immediately notify the issuing bank per UCP 600 Article 9(e): "If a bank is requested to advise a credit or amendment but elects not to do so, it must so inform, without delay, the bank from which the credit, amendment or advice has been received."
• (b) The issuing bank must re-route the advice to a bank with actual advising capacity. This re-routing does not constitute an amendment under Article 10 and requires no beneficiary consent.
• (c) If the issuing bank cannot re-route within a reasonable time, the applicant should be contacted to propose an alternative advise-through bank or to amend the credit under Article 10 procedures.

Resolution 3 — Beneficiary Protection Mechanism

When the beneficiary has not received advice of the credit due to a Field 57 failure:

• (a) The beneficiary should contact its own bank to determine whether the credit was received through any alternative channel (e.g., direct SWIFT copy from the issuing bank).
• (b) The beneficiary may request its bank to contact the issuing bank directly, citing UCP 600 Article 12(c): "Receipt or examination and forwarding of documents by a nominated bank that is not a confirming bank does not make that nominated bank liable to honour or negotiate, nor does it constitute honour or negotiation." This establishes that the absence of advice does not create an obligation on any downstream party.
• (c) If the credit has an expiry date approaching, the beneficiary should request an extension under Article 10 provisions, documenting the Field 57 failure as cause.

Conclusion

Field 57 of the MT700 is a routing field, not a substantive field. Its errors are deterministic: a wrong BIC code truncates the advisory chain, a duplicated BIC with Field 58 isolates the nominated bank's authority, and malformed data mutates the credit into an inaccessible state. The resolution architecture requires pre-transmission validation, receiving bank triage protocols, and beneficiary protection mechanisms that operate independently of the underlying trade transaction. Practitioners who isolate Field 57's function from the credit's availability architecture will avoid the systemic failures that currently generate the majority of LC discrepancies at the advisory stage.

FAQ

Q1: Can Field 57 and Field 58 contain the same bank's BIC code?

A: They can, but doing so creates a logical inconsistency. Field 57 instructs the issuing bank on where to send the advice; Field 58 nominates the bank for honour or negotiation. When both fields reference the same bank, the issuing bank is simultaneously designating the bank as a mere conduit (Field 57) and as a nominated actor (Field 58). Under UCP 600 Article 12, the nominated bank has no obligation to honour or negotiate unless expressly agreed. The duplication risks isolating the nominated bank's authority. Best practice dictates that Field 57 be left empty when the nominated bank in Field 58 is the intended advising path.

Q2: What happens if Field 57 contains an invalid or inactive BIC code?

A: The SWIFT network will reject the message at the transmission level, or the message will be delivered to an incorrect or inactive endpoint. UCP 600 Article 11(a) deems the teletransmission operative upon authenticated receipt, but receipt by a non-existent or inactive bank is not receipt for UCP purposes. The credit remains unissued in practical terms. The issuing bank must re-transmit with a valid BIC or without Field 57.

Q3: Is the applicant responsible for errors in Field 57?

A: Yes. ISBP 745, Preliminary Considerations, paragraph (v) states: "The applicant bears the risk of any ambiguity in its instructions to issue or amend a credit." Field 57 errors trace back to the applicant's credit application instructions. The issuing bank may supplement or develop those instructions per ISBP 745(v), but the ultimate liability for the error rests with the applicant.

Q4: Can an advising bank decline to advise because of Field 57 errors?

A: Yes. UCP 600 Article 9(e) explicitly permits this: "If a bank is requested to advise a credit or amendment but elects not to do so, it must so inform, without delay, the bank from which the credit, amendment or advice has been received." An advising bank is not obligated to advise a credit when it cannot satisfy itself as to apparent authenticity under Article 9(b), or when the Field 57 designation creates operational impossibility.

Q5: Does an empty Field 57 cause a discrepancy?

A: An empty Field 57 is not, by itself, a discrepancy. SWIFT field standards permit Field 57 to be omitted when the credit is to be advised directly by the issuing bank or through the nominated bank in Field 58. Under UCP 600 Article 14(d), data in a document need not be identical to, but must not conflict with, data in the credit. An absent Field 57 creates no conflict. The discrepancy arises only when Field 57 contains data that contradicts Field 58 or the credit's operative terms.