swift_mt_message/fields/
field23.rs

1use serde::{Deserialize, Serialize};
2use swift_mt_message_macros::SwiftField;
3
4///   **Field 23: Further Identification**
5///
6/// ## Purpose
7/// Provides additional identification information for financial transactions, particularly
8/// in money market and deposit transactions. This field enables precise categorization
9/// of transaction types, timing specifications, and reference information essential
10/// for proper transaction processing and regulatory compliance.
11///
12/// ## Format Specification
13/// - **Swift Format**: `3!a[2!n]11x`
14/// - **Structure**: Function code + optional days + reference information
15/// - **Total Length**: Maximum 16 characters
16/// - **Components**: Mandatory function code, conditional days, mandatory reference
17///
18/// ## Business Context Applications
19/// - **Money Market Transactions**: Deposit and call money operations
20/// - **Treasury Operations**: Interest rate and liquidity management
21/// - **Corporate Banking**: Commercial account management
22/// - **Settlement Processing**: Transaction categorization and routing
23///
24/// ## Function Code Categories
25/// ### Deposit Operations
26/// - **DEPOSIT**: Standard deposit transactions
27/// - **NOTICE**: Notice deposit with specific day requirements
28/// - **CALL**: Call money transactions (immediate settlement)
29/// - **CURRENT**: Current account operations
30///
31/// ### Commercial Operations
32/// - **COMMERCIAL**: Commercial transaction identification
33/// - **BASE**: Base rate reference transactions
34/// - **PRIME**: Prime rate related operations
35///
36/// ## Network Validation Requirements
37/// - **Function Code**: Must be valid 3-character alphabetic code
38/// - **Days Field**: Only required/allowed for NOTICE function code
39/// - **Days Range**: 1-99 days when specified for NOTICE transactions
40/// - **Reference Format**: Must comply with 11x character set restrictions
41/// - **Character Set**: Standard SWIFT character set compliance
42///
43/// ## Message Type Integration
44/// - **MT 200**: Financial institution transfer (function classification)
45/// - **MT 202**: General financial institution transfer (operation type)
46/// - **MT 210**: Notice to receive (notice period specification)
47/// - **Treasury Messages**: Various treasury operations requiring identification
48///
49/// ## Regional Considerations
50/// - **Money Market Standards**: Regional money market convention compliance
51/// - **Central Bank Requirements**: Regulatory classification requirements
52/// - **Settlement Systems**: Local settlement system integration
53/// - **Regulatory Reporting**: Transaction classification for reporting purposes
54///
55/// ## Validation Logic
56/// ### Function Code Rules
57/// - **NOTICE**: Requires days field (2!n format, 1-99)
58/// - **Other Codes**: Days field must not be present
59/// - **Reference**: Always required, 11x format compliance
60/// - **Character Validation**: Uppercase alphabetic characters only
61///
62/// ### Processing Impact
63/// - **Settlement Timing**: Function code affects settlement procedures
64/// - **Interest Calculation**: Impacts interest computation methods
65/// - **Regulatory Classification**: Determines reporting categories
66/// - **Risk Assessment**: Influences risk management procedures
67///
68/// ## Error Prevention Guidelines
69/// - **Function Code Verification**: Confirm valid function code selection
70/// - **Days Field Logic**: Only include days for NOTICE transactions
71/// - **Reference Accuracy**: Ensure reference information is correct
72/// - **Format Compliance**: Verify character set and length requirements
73///
74/// ## Related Fields Integration
75/// - **Field 20**: Transaction Reference (transaction context)
76/// - **Field 30**: Value Date (timing coordination)
77/// - **Field 32A**: Currency/Amount (transaction details)
78/// - **Field 52A/D**: Ordering Institution (institutional context)
79///
80/// ## Compliance Framework
81/// - **Money Market Regulations**: Compliance with money market standards
82/// - **Central Bank Reporting**: Regulatory classification requirements
83/// - **Audit Documentation**: Complete transaction categorization
84/// - **Risk Management**: Transaction type classification for risk assessment
85///
86/// ## Best Practices
87/// - **Accurate Classification**: Select appropriate function code
88/// - **Notice Period Management**: Proper days specification for NOTICE
89/// - **Reference Standards**: Consistent reference information format
90/// - **Documentation**: Complete transaction categorization documentation
91///
92/// ## See Also
93/// - Swift FIN User Handbook: Further Identification Field Specifications
94/// - Money Market Standards: Function Code Classifications
95/// - Treasury Operations Guide: Transaction Identification Best Practices
96#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, SwiftField)]
97pub struct Field23 {
98    /// Function code (3!a format: BASE, CALL, COMMERCIAL, CURRENT, DEPOSIT, NOTICE, PRIME)
99    #[component("3!a")]
100    pub function_code: String,
101    /// Number of days (2!n format, optional, only for NOTICE function)
102    #[component("2!n")]
103    pub days: Option<u8>,
104    /// Reference information (11x format)
105    #[component("11x")]
106    pub reference: String,
107}
108
109///   **Field 23B: Bank Operation Code**
110///
111/// ## Purpose
112/// Identifies the type of operation and associated service level for the payment instruction.
113/// This field determines processing rules, STP compliance requirements, and available service features.
114///
115/// ## Format
116/// - **Swift Format**: `4!c`
117/// - **Description**: Exactly 4 alphabetic characters (uppercase)
118/// - **Character Set**: A-Z only, no numbers or special characters
119///
120/// ## Presence
121/// - **Status**: Mandatory in MT103, MT102, and related payment messages
122/// - **Swift Error Codes**: T12 (invalid code), T15 (field not allowed)
123/// - **Referenced in Rules**: C3, C4, C5, C6, C8, C10, C11, C12 (MT103)
124///
125/// ## Valid Codes
126/// - **CRED**: Normal credit transfer (no specific SWIFT Service Level)
127/// - **CRTS**: Test message (should not be processed on FIN network)
128/// - **SPAY**: SWIFTPay Service Level (premium service)
129/// - **SPRI**: Priority Service Level (highest priority)
130/// - **SSTD**: Standard Service Level (standard processing)
131///
132/// ## Network Validation Rules
133/// - **C3**: If SPRI → field 23E restricted to SDVA, TELB, PHOB, INTC only
134/// - **C3**: If SSTD or SPAY → field 23E must not be present
135/// - **C4**: Service levels affect correspondent institution field requirements
136/// - **C6**: SPRI requires specific BIC validation for certain regions
137/// - **C10**: If SPRI → field 56a (Intermediary) must not be present
138/// - **C12**: Service levels mandate beneficiary account requirements
139///
140/// ## Usage Rules
141/// - **Service Level Selection**: Choose based on urgency and STP requirements
142/// - **Cost Implications**: SPRI and SPAY typically incur higher fees
143/// - **Processing Time**: SPRI processes faster than SSTD, CRED has standard timing
144/// - **STP Compliance**: SPRI, SPAY, SSTD enable straight-through processing
145///
146/// ## STP Compliance
147/// - **STP-Enabled Codes**: SPRI, SPAY, SSTD
148/// - **Non-STP Code**: CRED (legacy processing)
149/// - **Additional Restrictions**: STP codes have stricter field format requirements
150/// - **Correspondent Constraints**: Service levels limit correspondent field options
151///
152/// ## Regional Considerations
153/// - **EU/EEA**: Service level affects SEPA compliance and processing routes
154/// - **Correspondents**: Some institutions only support specific service levels
155/// - **Settlement**: Service level determines settlement timing and priority
156///
157/// ## Examples
158/// ```logic
159/// :23B:CRED    // Normal credit transfer
160/// :23B:SPRI    // Priority service level
161/// :23B:SSTD    // Standard service level  
162/// :23B:SPAY    // SWIFTPay service
163/// ```
164///
165/// ## Related Fields
166/// - **Field 23E**: Instruction Code (availability depends on 23B value)
167/// - **Field 13C**: Time Indication (may be required for certain service levels)
168/// - **Field 72**: Sender to Receiver Information (service level details)
169///
170/// ## Error Handling
171/// - **Invalid Code**: Results in T12 error and message rejection
172/// - **Rule Violations**: Service level constraints trigger specific C-rule errors
173/// - **STP Failures**: Non-compliant combinations cause processing delays
174///
175/// ## See Also
176/// - Swift FIN User Handbook: Service Level Definitions
177/// - MT103 Usage Rules: Bank Operation Code Guidelines
178/// - STP Implementation Guide: Service Level Requirements
179#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, SwiftField)]
180pub struct Field23B {
181    /// Bank operation code indicating service level and processing type
182    ///
183    /// Format: 4!c - Exactly 4 alphabetic characters
184    /// Valid codes: CRED, CRTS, SPAY, SPRI, SSTD
185    #[component("4!c")]
186    pub instruction_code: String,
187}
188
189///   **Field 23E: Instruction Code**
190///
191/// ## Purpose
192/// Specifies detailed payment instructions and processing directives that complement
193/// the bank operation code in Field 23B. This field provides granular control over
194/// payment processing, delivery methods, and special handling requirements essential
195/// for precise transaction execution and compliance with specific service levels.
196///
197/// ## Format Specification
198/// - **Swift Format**: `4!c[/30x]`
199/// - **Structure**: Mandatory instruction code + optional additional information
200/// - **Instruction Code**: Exactly 4 alphabetic characters (uppercase)
201/// - **Additional Info**: Up to 30 characters for supplementary details
202///
203/// ## Business Context Applications
204/// - **Payment Instructions**: Specific delivery and processing directives
205/// - **Service Level Compliance**: Instructions aligned with Field 23B service levels
206/// - **Special Handling**: Non-standard processing requirements
207/// - **Delivery Methods**: Communication and notification preferences
208///
209/// ## Instruction Code Categories
210/// ### Standard Delivery Instructions
211/// - **SDVA**: Same day value (immediate processing)
212/// - **TELB**: Telephone beneficiary before crediting
213/// - **PHOB**: Phone beneficiary organization before payment
214/// - **INTC**: Intermediary contact required
215///
216/// ### Communication Instructions
217/// - **TELE**: Telephone advice required
218/// - **TELEAUTH**: Telephone authorization needed
219/// - **HOLD**: Hold payment for specific conditions
220/// - **RETN**: Return if undeliverable
221///
222/// ## Network Validation Requirements
223/// - **Service Level Constraints**: Availability depends on Field 23B value
224/// - **SPRI Service**: Only SDVA, TELB, PHOB, INTC allowed with Priority Service
225/// - **SSTD/SPAY Services**: Field 23E must not be present
226/// - **Character Set**: Standard SWIFT character set for additional information
227/// - **Length Validation**: Additional info maximum 30 characters
228///
229/// ## Field 23B Integration Rules
230/// ### Priority Service Level (SPRI)
231/// - **Allowed Codes**: SDVA, TELB, PHOB, INTC only
232/// - **Processing Impact**: Immediate execution requirements
233/// - **Validation Rule**: C3 constraint enforcement
234/// - **STP Compliance**: Enhanced straight-through processing
235///
236/// ### Standard/SWIFTPay Service (SSTD/SPAY)
237/// - **Field Restriction**: Field 23E must not be present
238/// - **Automated Processing**: No manual intervention instructions
239/// - **STP Requirements**: Full automation compliance
240/// - **Error Prevention**: C3 rule violation avoidance
241///
242/// ## Regional Considerations
243/// - **Local Practices**: Regional instruction code interpretation
244/// - **Central Bank Rules**: Regulatory instruction requirements
245/// - **Correspondent Capabilities**: Institution-specific instruction support
246/// - **Settlement Systems**: Local system instruction integration
247///
248/// ## Processing Impact
249/// ### Same Day Value (SDVA)
250/// - **Timing**: Immediate value date processing
251/// - **Priority**: High priority execution
252/// - **Settlement**: Same day settlement requirements
253/// - **Cost**: Potential premium charges
254///
255/// ### Communication Requirements (TELB/PHOB)
256/// - **Manual Intervention**: Human contact required
257/// - **Processing Delay**: Additional processing time
258/// - **Verification**: Beneficiary confirmation needed
259/// - **Documentation**: Contact record maintenance
260///
261/// ## Error Prevention Guidelines
262/// - **Service Level Validation**: Verify compatibility with Field 23B
263/// - **Instruction Appropriateness**: Confirm instruction necessity
264/// - **Additional Info Format**: Ensure character set compliance
265/// - **Processing Capability**: Verify recipient institution capability
266///
267/// ## Related Fields Integration
268/// - **Field 23B**: Bank Operation Code (service level dependency)
269/// - **Field 13C**: Time Indication (timing coordination)
270/// - **Field 72**: Sender to Receiver Information (instruction context)
271/// - **Field 57A**: Account with Institution (delivery coordination)
272///
273/// ## Compliance Framework
274/// - **Service Level Agreements**: Instruction compliance with SLAs
275/// - **Regulatory Requirements**: Instruction regulatory compliance
276/// - **Operational Procedures**: Standard operating procedure alignment
277/// - **Audit Documentation**: Instruction rationale documentation
278///
279/// ## Usage Examples
280/// ```logic
281/// :23E:SDVA             // Same day value instruction
282/// :23E:TELB/URGENT      // Telephone beneficiary with urgency note
283/// :23E:PHOB/CONFIRM     // Phone organization with confirmation required
284/// :23E:INTC/AUTH REQ    // Intermediary contact with authorization request
285/// ```
286///
287/// ## Best Practices
288/// - **Selective Usage**: Only include when necessary for processing
289/// - **Service Level Alignment**: Ensure compatibility with Field 23B
290/// - **Clear Instructions**: Provide clear additional information
291/// - **Cost Consideration**: Understand fee implications of special instructions
292///
293/// ## See Also
294/// - Swift FIN User Handbook: Instruction Code Specifications
295/// - MT103 Usage Rules: Field 23E Implementation Guidelines
296/// - Service Level Guide: Instruction Code Compatibility Matrix
297#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, SwiftField)]
298pub struct Field23E {
299    /// Instruction code
300    #[component("4!c")]
301    pub instruction_code: String,
302    /// Additional information (optional)
303    #[component("[/30x]")]
304    pub additional_info: Option<String>,
305}
swift_mt_message/fields/field23.rs

swift_mt_message/fields/
field23.rs
