swift_mt_message/messages/
mt192.rs

1use crate::fields::*;
2use serde::{Deserialize, Serialize};
3use swift_mt_message_macros::{SwiftMessage, serde_swift_fields};
4
5/// MT192: Request for Cancellation
6///
7/// ## Purpose
8/// Used by the originator to request the cancellation of a previously sent payment message before execution.
9/// This message provides precise reference information to identify the specific message to be cancelled and
10/// includes optional reason codes for the cancellation request, enabling proper payment lifecycle management.
11///
12/// ## Scope
13/// This message is:
14/// - Used for cancellation requests by originators of previously sent payment messages
15/// - Applicable for preventing execution of payment instructions before settlement
16/// - Designed for urgent processing to halt payment execution workflows
17/// - Compatible with various payment message types requiring cancellation
18/// - Subject to validation rules for proper message identification and tracking
19/// - Integrated with payment processing systems for real-time cancellation requests
20///
21/// ## Key Features
22/// - **Precise Message Identification**: Complete reference to original message requiring cancellation
23/// - **Urgent Cancellation Processing**: Time-sensitive processing to prevent payment execution
24/// - **Session-Based Tracking**: Field 11S for accurate session-based message identification
25/// - **Comprehensive Reason Codes**: Optional detailed information about cancellation reasons
26/// - **Original Message Reconstruction**: Optional inclusion of original message field copies
27/// - **Audit Trail Maintenance**: Complete tracking of cancellation requests and outcomes
28///
29/// ## Common Use Cases
30/// - Duplicate payment prevention for inadvertent double submissions
31/// - Incorrect payment details correction before execution
32/// - Customer-initiated cancellation requests for payment changes
33/// - System error recovery and payment correction procedures
34/// - Fraud prevention and suspicious payment halting
35/// - Regulatory compliance-driven payment cancellations
36/// - Emergency cancellation for financial institution risk management
37///
38/// ## Message Structure
39/// - **Field 20**: Sender's Reference (mandatory) - Unique reference for cancellation request
40/// - **Field 21**: Related Reference (mandatory) - Reference to original message being cancelled
41/// - **Field 11S**: MT and Date (mandatory) - Session details of original message (MT+date+session+sequence)
42/// - **Field 79**: Narrative (optional) - Cancellation reason codes and additional information
43/// - **Original Message Fields**: Optional copies of fields from original message for verification
44///
45/// ## Network Validation Rules
46/// - **Reference Format Validation**: Reference fields must not start/end with '/' or contain '//'
47/// - **Session Reference Format**: Field 11S must have proper format for MT, date, session, and sequence numbers
48/// - **Information Requirement**: Either field 79 or copies of original message fields must be present
49/// - **Reason Code Validation**: Field 79 should contain valid cancellation reason codes when present
50/// - **Message Type Consistency**: Field 11S message type must match valid payment message types
51/// - **Date Format Validation**: Date in field 11S must be in valid YYMMDD format
52/// - **Sequence Number Validation**: Session and sequence numbers must be properly formatted
53///
54/// ## SRG2025 Status
55/// - **Structural Changes**: None - MT192 format remains stable for cancellation processing
56/// - **Validation Updates**: Enhanced validation for session reference accuracy and reason codes
57/// - **Processing Improvements**: Improved handling of urgent cancellation request processing
58/// - **Compliance Notes**: Strengthened requirements for audit trail and regulatory reporting
59///
60/// ## Integration Considerations
61/// - **Banking Systems**: Compatible with payment processing engines and workflow management systems
62/// - **API Integration**: RESTful API support for modern digital banking cancellation requests
63/// - **Processing Requirements**: Supports urgent processing with real-time cancellation capabilities
64/// - **Compliance Integration**: Built-in validation for regulatory cancellation requirements and reporting
65///
66/// ## Relationship to Other Messages
67/// - **Triggers**: Triggered by payment processing systems, customer requests, or risk management systems
68/// - **Responses**: Generates MT196 response messages confirming cancellation status
69/// - **Related**: Works with original payment messages (MT103, MT202, etc.) requiring cancellation
70/// - **Alternatives**: Direct system-level cancellation for internal processing corrections
71/// - **Status Updates**: May receive status notifications about cancellation success or failure
72#[serde_swift_fields]
73#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, SwiftMessage)]
74#[validation_rules(MT192_VALIDATION_RULES)]
75pub struct MT192 {
76    #[field("20")]
77    pub field_20: Field20,
78
79    #[field("21")]
80    pub field_21: Field21NoOption,
81
82    #[field("11S")]
83    pub field_11s: Field11S,
84
85    #[field("79")]
86    pub field_79: Option<Field79>,
87}
88
89/// Enhanced validation rules for MT192
90const MT192_VALIDATION_RULES: &str = r#"{
91  "rules": [
92    {
93      "id": "C1",
94      "description": "Either Field 79 or a copy of mandatory fields from the original message (or both) must be present",
95      "condition": {
96        "!!": {"var": "fields.79"}
97      }
98    }
99  ]
100}"#;
swift_mt_message/messages/mt192.rs

swift_mt_message/messages/
mt192.rs
