swift_mt_message/messages/
mt296.rs

1use crate::fields::*;
2use serde::{Deserialize, Serialize};
3use swift_mt_message_macros::{SwiftMessage, serde_swift_fields};
4
5/// MT296: Answers (Category 2 - Financial Institution Transfers)
6///
7/// ## Purpose
8/// Used to provide answers or responses to various queries and requests related to Category 2
9/// financial institution transfers. This message responds to different types of inquiries,
10/// including cancellation requests (MT292) and other operational queries.
11///
12/// ## Scope
13/// This message is:
14/// - Sent in response to MT292 cancellation requests and other Category 2 inquiries
15/// - Used to provide structured answers with detailed status information
16/// - Contains response codes and explanatory text for institutional transfer queries
17/// - Supports various inquiry types with flexible narrative content
18/// - Essential for treasury operations and institutional transfer management
19///
20/// ## Key Features
21/// - **Query Response**: Structured response to various types of institutional transfer inquiries
22/// - **Reference Tracking**: Links to original query or request message through field 21
23/// - **Answer Codes**: Field 76 provides structured answers with specific codes
24/// - **Status Information**: Clear indication of query resolution and outcome
25/// - **Flexible Format**: Adaptable to different types of institutional transfer inquiries
26/// - **Optional Narrative**: Field 79 for additional explanatory information
27///
28/// ## Common Use Cases
29/// - Response to MT292 cancellation requests (accept/reject/partial)
30/// - Status updates on institutional transfer processing
31/// - Inquiry responses about transaction details and settlement status
32/// - Error resolution and clarification messages for treasury operations
33/// - Settlement system status communications
34/// - Correspondent banking operational responses
35/// - Cross-border institutional transfer confirmations
36///
37/// ## Field Structure
38/// - **20**: Sender's Reference (mandatory) - Reference for this answer message
39/// - **21**: Related Reference (mandatory) - Reference to original inquiry/request
40/// - **76**: Answers (mandatory) - Structured answer codes and information
41/// - **77A**: Optional Query Section (optional) - Additional query details
42/// - **11**: MT and Date Reference (optional) - Reference to specific original message
43/// - **79**: Narrative (optional) - Additional explanatory text
44///
45/// ## Field 76 Answer Codes
46/// The Field 76 contains structured answer codes that may include:
47/// - **ACCEPTED**: Request has been accepted and processed
48/// - **REJECTED**: Request has been rejected with reason
49/// - **PARTIAL**: Partial acceptance/processing of request
50/// - **PENDING**: Request is under review/processing
51/// - **COMPLETED**: Processing has been completed
52/// - **ERROR**: Error encountered during processing
53/// - **TIMEOUT**: Request timed out or expired
54/// - **DUPLICATE**: Duplicate request detected
55/// - **INVALID**: Invalid request format or content
56///
57/// ## Network Validation Rules
58/// - **C1 Rule**: Field 79 or copy of original message fields may be present, but not both
59/// - **Reference Format**: All reference fields must follow SWIFT formatting conventions
60/// - **Field 11A Format**: When present, must have proper format with valid MT reference
61/// - **Required Fields**: All mandatory fields must be present and non-empty
62/// - **Answer Code Validation**: Field 76 must contain valid, recognizable answer codes
63/// - **Conditional Fields**: Optional fields must follow proper conditional logic
64///
65/// ## Answer Processing Types
66/// ### Cancellation Responses (to MT292)
67/// - **CANC**: Cancellation accepted and processed
68/// - **RJCT**: Cancellation rejected (payment already processed)
69/// - **PART**: Partial cancellation (only some transactions cancelled)
70/// - **NPAY**: No payment found matching cancellation request
71///
72/// ### Status Responses
73/// - **ACPT**: Message accepted for processing
74/// - **PROC**: Currently processing
75/// - **SETT**: Settlement completed
76/// - **FAIL**: Processing failed
77///
78/// ### Information Responses
79/// - **INFO**: Informational response provided
80/// - **CONF**: Confirmation of status or details
81/// - **NFND**: Requested information not found
82/// - **RSTR**: Restricted information (access denied)
83///
84/// ## Processing Considerations
85/// - **Timely Response**: Should be sent promptly after receiving inquiry
86/// - **Accurate Status**: Must reflect current and accurate status information
87/// - **Clear Communication**: Answer codes should be unambiguous
88/// - **Audit Trail**: Maintains record of all query-response interactions
89/// - **Follow-up**: May trigger additional operational actions
90///
91/// ## SRG2025 Status
92/// - **Structural Changes**: None - MT296 format remains unchanged in SRG2025
93/// - **Validation Updates**: Enhanced validation for institutional transfer responses
94/// - **Processing Improvements**: Improved validation for answer code consistency
95/// - **Compliance Notes**: Better integration with modern settlement systems
96///
97/// ## Integration Considerations
98/// - **Banking Systems**: Compatible with treasury management and customer service systems
99/// - **API Integration**: RESTful API support for modern institutional transfer response platforms
100/// - **Processing Requirements**: Supports real-time response generation with audit capabilities
101/// - **Compliance Integration**: Built-in validation for regulatory response requirements
102///
103/// ## Relationship to Other Messages
104/// - **Triggers**: Directly triggered by MT292 cancellation requests and Category 2 inquiries
105/// - **Responses**: Provides definitive responses to institutional transfer requests
106/// - **Related**: Works with Category 2 messages and operational workflow systems
107/// - **Alternatives**: Direct system notifications for internal processing status updates
108/// - **Status Updates**: Final response message in institutional transfer inquiry lifecycle
109
110#[serde_swift_fields]
111#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, SwiftMessage)]
112#[validation_rules(MT296_VALIDATION_RULES)]
113pub struct MT296 {
114    #[field("20")]
115    pub field_20: Field20,
116
117    #[field("21")]
118    pub field_21: Field21NoOption,
119
120    #[field("76")]
121    pub field_76: Field76,
122
123    #[field("77A")]
124    pub field_77a: Option<Field77A>,
125
126    #[field("11")]
127    pub field_11: Option<Field11>,
128
129    #[field("79")]
130    pub field_79: Option<Field79>,
131}
132
133/// Enhanced validation rules for MT296
134const MT296_VALIDATION_RULES: &str = r#"{
135  "rules": [
136    {
137      "id": "C1",
138      "description": "Only one of the following may be present: Field 79, or a copy of mandatory fields of the original message",
139      "condition": {
140        "!": {"exists": ["fields", "79"]}
141      }
142    }
143  ]
144}"#;