swift_mt_message/fields/field34.rs
1use serde::{Deserialize, Serialize};
2use swift_mt_message_macros::SwiftField;
3
4/// **Field 34F: Floor Limit**
5///
6/// ## Purpose
7/// Specifies the floor limit amount and currency for automatic processing thresholds
8/// in financial transactions. This field defines minimum amounts for automated handling,
9/// exception processing triggers, and regulatory compliance thresholds. Floor limits
10/// enable institutions to manage risk and processing efficiency through amount-based routing.
11///
12/// ## Format
13/// - **Swift Format**: `3!a[1!a]15d`
14/// - **Currency Component**: `3!a` - ISO 4217 currency code
15/// - **Indicator Component**: `[1!a]` - Optional floor limit indicator (D or C)
16/// - **Amount Component**: `15d` - Decimal amount with comma separator
17///
18/// ## Presence
19/// - **Status**: Optional in most contexts, mandatory for specific processing requirements
20/// - **Swift Error Codes**: T52 (invalid currency), T40/T43 (invalid amount), T50 (invalid indicator)
21/// - **Usage Context**: Automated processing thresholds and risk management
22///
23/// ## Usage Rules
24/// - **Threshold Definition**: Defines minimum amount for specific processing treatment
25/// - **Indicator Logic**: D (Debit) or C (Credit) specifies threshold direction
26/// - **Currency Alignment**: Must align with transaction currency context
27/// - **Processing Logic**: Determines automated vs. manual processing paths
28///
29/// ## Network Validation Rules
30/// - **Currency Validation**: Must be valid ISO 4217 currency code
31/// - **Amount Format**: Decimal comma mandatory, proper precision required
32/// - **Positive Amount**: Amount must be greater than zero
33/// - **Indicator Validation**: If present, must be 'D' (Debit) or 'C' (Credit)
34/// - **Logic Validation**: Must be consistent with business processing rules
35///
36/// ## Floor Limit Indicators
37///
38/// ### D (Debit) Indicator
39/// - **Purpose**: Threshold for debit transactions
40/// - **Processing**: Amounts below threshold may receive automated processing
41/// - **Risk Management**: Higher amounts trigger enhanced controls
42/// - **Usage Context**: Payment instructions, fund transfers
43///
44/// ### C (Credit) Indicator
45/// - **Purpose**: Threshold for credit transactions
46/// - **Processing**: Credits below threshold may bypass certain checks
47/// - **Compliance**: Regulatory thresholds for credit processing
48/// - **Usage Context**: Incoming payments, deposit processing
49///
50/// ### No Indicator
51/// - **Purpose**: General threshold regardless of direction
52/// - **Processing**: Applies to both debit and credit transactions
53/// - **Usage Context**: Universal processing limits
54///
55/// ## Business Context
56/// - **Risk Management**: Automated risk assessment based on transaction amounts
57/// - **Processing Efficiency**: Streamlined handling for routine transactions
58/// - **Regulatory Compliance**: Meeting regulatory threshold requirements
59/// - **Cost Management**: Efficient processing of high-volume, low-value transactions
60///
61/// ## Examples
62/// ```logic
63/// :34F:USD5000,00 // USD 5,000 general floor limit
64/// :34F:USDD2500,00 // USD 2,500 debit threshold
65/// :34F:EURC1000,00 // EUR 1,000 credit threshold
66/// :34F:GBP10000,00 // GBP 10,000 general limit
67/// ```
68///
69/// ## Processing Applications
70/// - **Automated Processing**: Transactions below threshold receive automated handling
71/// - **Manual Review**: Transactions above threshold require manual intervention
72/// - **STP Qualification**: Floor limits determine STP eligibility
73/// - **Exception Processing**: Threshold-based exception routing
74///
75/// ## Risk Management Integration
76/// - **Amount-Based Controls**: Different control levels based on transaction size
77/// - **Automated Monitoring**: System-driven monitoring for threshold breaches
78/// - **Escalation Procedures**: Automatic escalation for amounts exceeding limits
79/// - **Audit Trail**: Comprehensive logging of threshold applications
80///
81/// ## Regional Considerations
82/// - **European Markets**: SEPA processing thresholds and regulations
83/// - **US Markets**: Federal Reserve and ACH processing limits
84/// - **Asian Markets**: Local regulatory threshold requirements
85/// - **Cross-Border**: International processing limit coordination
86///
87/// ## Regulatory Framework
88/// - **AML Thresholds**: Anti-money laundering reporting thresholds
89/// - **KYC Requirements**: Know-your-customer enhanced due diligence limits
90/// - **Sanctions Screening**: Enhanced screening for high-value transactions
91/// - **Reporting Obligations**: Regulatory reporting threshold compliance
92///
93/// ## Error Prevention
94/// - **Threshold Validation**: Verify floor limit is appropriate for context
95/// - **Currency Consistency**: Ensure currency aligns with transaction context
96/// - **Amount Verification**: Confirm amount format and precision
97/// - **Business Logic**: Validate threshold makes business sense
98///
99/// ## Related Fields
100/// - **Field 32A**: Value Date, Currency, Amount (transaction amount comparison)
101/// - **Field 33B**: Currency/Instructed Amount (original amount context)
102/// - **Field 71A**: Details of Charges (charge-related thresholds)
103/// - **Processing Rules**: System configuration for threshold handling
104///
105/// ## Threshold Management
106/// - **Dynamic Limits**: Ability to adjust thresholds based on risk profiles
107/// - **Customer-Specific**: Different limits for different customer categories
108/// - **Product-Specific**: Varying thresholds for different transaction types
109/// - **Time-Based**: Different limits for different processing windows
110///
111/// ## STP Compliance
112/// - **Threshold Standardization**: Consistent floor limit application
113/// - **Automated Processing**: System-driven threshold evaluation
114/// - **Exception Handling**: Automated routing based on threshold breaches
115/// - **Quality Control**: Real-time threshold validation and application
116///
117/// ## Compliance and Audit
118/// - **Regulatory Alignment**: Floor limits aligned with regulatory requirements
119/// - **Audit Documentation**: Complete record of threshold applications
120/// - **Investigation Support**: Threshold-based transaction analysis
121/// - **Risk Assessment**: Regular review and adjustment of floor limits
122///
123/// ## See Also
124/// - Swift FIN User Handbook: Floor Limit Specifications
125/// - Risk Management Guidelines: Amount-Based Processing Controls
126/// - Regulatory Standards: Transaction Threshold Requirements
127/// - Processing Manuals: Automated vs. Manual Transaction Handling
128/// **Field 34F: Floor Limit Structure**
129///
130/// Contains currency, optional indicator, and amount for processing threshold definition.
131#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, SwiftField)]
132pub struct Field34F {
133 /// Currency code for floor limit
134 ///
135 /// Format: 3!a - ISO 4217 currency code (USD, EUR, GBP, etc.)
136 /// Must be valid currency for threshold processing context
137 #[component("3!a")]
138 pub currency: String,
139
140 /// Floor limit indicator
141 ///
142 /// Format: \[1!a\] - Optional indicator: 'D' (Debit) or 'C' (Credit)
143 /// Specifies whether threshold applies to debits, credits, or both (if omitted)
144 #[component("[1!a]")]
145 pub indicator: Option<String>,
146
147 /// Floor limit amount
148 ///
149 /// Format: 15d - Decimal amount with comma separator
150 /// Defines the threshold amount for automated processing decisions
151 #[component("15d")]
152 pub amount: f64,
153}