Struct Field23B

pub struct Field23B {
    pub instruction_code: String,
}

Field 23B: Bank Operation Code

Purpose

Identifies the type of operation and associated service level for the payment instruction. This field determines processing rules, STP compliance requirements, and available service features.

Format

• Swift Format: 4!c
• Description: Exactly 4 alphabetic characters (uppercase)
• Character Set: A-Z only, no numbers or special characters

Presence

• Status: Mandatory in MT103, MT102, and related payment messages
• Swift Error Codes: T12 (invalid code), T15 (field not allowed)
• Referenced in Rules: C3, C4, C5, C6, C8, C10, C11, C12 (MT103)

Valid Codes

• CRED: Normal credit transfer (no specific SWIFT Service Level)
• CRTS: Test message (should not be processed on FIN network)
• SPAY: SWIFTPay Service Level (premium service)
• SPRI: Priority Service Level (highest priority)
• SSTD: Standard Service Level (standard processing)

Network Validation Rules

• C3: If SPRI → field 23E restricted to SDVA, TELB, PHOB, INTC only
• C3: If SSTD or SPAY → field 23E must not be present
• C4: Service levels affect correspondent institution field requirements
• C6: SPRI requires specific BIC validation for certain regions
• C10: If SPRI → field 56a (Intermediary) must not be present
• C12: Service levels mandate beneficiary account requirements

Usage Rules

• Service Level Selection: Choose based on urgency and STP requirements
• Cost Implications: SPRI and SPAY typically incur higher fees
• Processing Time: SPRI processes faster than SSTD, CRED has standard timing
• STP Compliance: SPRI, SPAY, SSTD enable straight-through processing

STP Compliance

• STP-Enabled Codes: SPRI, SPAY, SSTD
• Non-STP Code: CRED (legacy processing)
• Additional Restrictions: STP codes have stricter field format requirements
• Correspondent Constraints: Service levels limit correspondent field options

Regional Considerations

• EU/EEA: Service level affects SEPA compliance and processing routes
• Correspondents: Some institutions only support specific service levels
• Settlement: Service level determines settlement timing and priority

Examples

:23B:CRED    // Normal credit transfer
:23B:SPRI    // Priority service level
:23B:SSTD    // Standard service level  
:23B:SPAY    // SWIFTPay service

Related Fields

• Field 23E: Instruction Code (availability depends on 23B value)
• Field 13C: Time Indication (may be required for certain service levels)
• Field 72: Sender to Receiver Information (service level details)

Error Handling

• Invalid Code: Results in T12 error and message rejection
• Rule Violations: Service level constraints trigger specific C-rule errors
• STP Failures: Non-compliant combinations cause processing delays

See Also

• Swift FIN User Handbook: Service Level Definitions
• MT103 Usage Rules: Bank Operation Code Guidelines
• STP Implementation Guide: Service Level Requirements

Fields

instruction_code: String

Bank operation code indicating service level and processing type

Format: 4!c - Exactly 4 alphabetic characters Valid codes: CRED, CRTS, SPAY, SPRI, SSTD

Trait Implementations

impl Clone for Field23B

fn clone(&self) -> Field23B

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for Field23B

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

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Field23B

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for Field23B

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

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 Field23B

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 Field23B