मुख्य सामग्री पर जाएं
बिजनेस कंसोल की हर नियम-सुविधा प्रोग्राम के ज़रिए भी उपलब्ध है: आपकी एप्लिकेशन API कुंजी के साथ Management API के माध्यम से, और साइन-इन किए हुए कंसोल उपयोगकर्ता के रूप में काम करने वाले AI एजेंटों के लिए Didit MCP के माध्यम से। इनका उपयोग कोड से नियम प्रबंधित करने, नियम-सेट को संस्करण नियंत्रण में रखने, या AI सहायक से आपके लिए नियम बनाने और माइग्रेट करने के लिए करें।

किस सतह का उपयोग कब करें

endpoint

संबंधित MCP टूल ये हैं: didit_transaction_rule_list, didit_transaction_rule_get, didit_transaction_rule_create, didit_transaction_rule_update, didit_transaction_rule_delete, didit_transaction_rule_backtest, didit_transaction_rule_library_list, didit_transaction_rule_install, और didit_transaction_rule_uninstall - विवरण के लिए MCP टूल संदर्भ देखें। पूर्ण स्कीमा - फ़ील्ड कैटलॉग, सभी 19 कंडीशन ऑपरेटर, वेलोसिटी विंडो, समूहित कंडीशन, और छह कार्रवाई प्रकार - नियम और स्कोरिंग पेज पर दस्तावेज़ित है और API संदर्भ में भी शामिल है।

बनाएँ, बैकटेस्ट करें, सक्रिय करें

किसी भी नए नियम के लिए सुरक्षित रोलआउट पैटर्न:
1

TEST मोड में नियम बनाएँ

payload को दो हिस्सों में पढ़ें। scope और conditions मूल्यांकित किए जा रहे लेन-देन का वर्णन करते हैं: EUR में एक इनबाउंड फ़ाइनेंस लेन-देन जिसका कच्चा amount 10,000 से कम है। aggregation प्रविष्टियाँ उसी विषय के लिए 30-दिन की विंडो का वर्णन करती हैं: कम से कम 20 इनबाउंड EUR फ़ाइनेंस लेन-देन, और उनमें से कोई भी 10,000 EUR या उससे अधिक का नहीं। evaluation_mode जो भी कहे, दोनों aggregation प्रविष्टियों का सत्य होना ज़रूरी है - वह सेटिंग केवल conditions को नियंत्रित करती है।यह उदाहरण कच्चे amount का उपयोग करता है और दोनों हिस्सों में currency को EUR पर तय करता है, इसलिए यह FX सामान्यीकरण पर निर्भर नहीं करता। सैंडबॉक्स टेस्ट डेटा पर बैकटेस्ट करने के लिए, उसी विषय के लिए 30 दिनों के भीतर कम से कम 20 इनबाउंड EUR फ़ाइनेंस लेन-देन सबमिट करें, जिनमें से हर एक का amount 10,000 से कम हो। न preferred_currency_amount और न ही amount_in_default_currency आवश्यक है। सैंडबॉक्स डेटा अंतर्ग्रहण इन लेन-देन को संग्रहीत करता है; बैकटेस्ट स्पष्ट रूप से चलाएँ।TEST नियम हर नए लेन-देन का मूल्यांकन करता है और दर्ज करता है कि वह किन लेन-देन से मेल खाता, लेकिन लेन-देन के स्कोर या स्थिति को कभी नहीं छूता।
एक aggregation फ़िल्टर कंडीशन नहीं है। कंडीशन केवल मूल्यांकित किए जा रहे लेन-देन को पढ़ती है; aggregation फ़िल्टर केवल ऐतिहासिक विंडो को सीमित करता है, और वह समानता या सूची-सदस्यता से तुलना करता है - कोई lt फ़िल्टर नहीं है, इसलिए आप केवल 10,000 से कम के ट्रांसफ़र नहीं गिन सकते।max ... lt 10000 प्रविष्टि विंडो पर ऊपरी सीमा लगाने का समर्थित तरीका है: इसके लिए विंडो के हर लेन-देन का 10,000 से कम होना ज़रूरी है, जो केवल छोटे लेन-देन गिनने से अधिक सख़्त है - बीस में से एक 12,000 का ट्रांसफ़र भी नियम को चलने से रोक देता है। यदि आप चाहें कि गिनती स्वतंत्र रूप से की जाए, तो वह प्रविष्टि हटा दें, और फिर शीर्षक में यह स्पष्ट लिखें: उसके बिना नियम किसी भी आकार के इनबाउंड ट्रांसफ़र गिनता है, और उन्नीस 50,000 के ट्रांसफ़र के बाद एक छोटा ट्रांसफ़र आए तो नियम मेल खा जाता है।
2

अपने इतिहास के विरुद्ध बैकटेस्ट करें

matched की कोई अप्रत्याशित गिनती बताती है कि नियम कुछ भी कर सके, उससे पहले थ्रेशोल्ड को ट्यून करने की ज़रूरत है।
जिस सटीक कॉन्फ़िगरेशन को आप सक्रिय करने जा रहे हैं, उसी का बैकटेस्ट करें: वही conditions, aggregation, evaluation_mode और scope। छोड़े गए conditions, aggregation और scope अपनी ओर से कोई बाधा नहीं जोड़ते; scope हटाने से ऐसी दिशाएँ या लेन-देन प्रकार शामिल हो सकते हैं जिन्हें सहेजा गया नियम छोड़ देता है। छोड़ा गया evaluation_mode डिफ़ॉल्ट रूप से ALL होता है, इसलिए ANY नियम के लिए इसे छोड़ने से मिलान कम हो सकते हैं। छोड़ा गया period_days डिफ़ॉल्ट रूप से 90 दिन होता है; यह असीमित इतिहास का चयन नहीं करता।
3

सक्रिय करें

नियम किसी लाइव एप्लिकेशन के सभी नए लेन-देन पर तुरंत लागू होता है।
सैंडबॉक्स एप्लिकेशन कभी नियमों का मूल्यांकन नहीं करते। सैंडबॉक्स लेन-देन केवल संग्रहीत होता है, और कुछ नहीं; इसलिए सैंडबॉक्स एप्लिकेशन पर नियम सक्रिय करने से ऐसा कुछ नहीं बदलता जिसे आप देख सकें। लाइव होने से पहले नियम को परखने का समर्थित तरीका बैकटेस्ट है - सैंडबॉक्स में लेन-देन निगरानी देखें।

किसी अन्य प्रदाता से नियम माइग्रेट करना

चूँकि नियम बनाना पूरी तरह दस्तावेज़ित स्कीमा वाली एक सामान्य API कॉल है, इसलिए एक AI सहायक किसी दूसरे प्रदाता के नियम एक्सपोर्ट को आपके लिए Didit नियमों में बदल सकता है।
  1. अपने मौजूदा प्रदाता से अपने नियम एक्सपोर्ट करें - ज़्यादातर टूल CSV या Excel में एक्सपोर्ट करते हैं।
  2. फ़ाइल को Didit कंसोल सहायक में डालें (या Didit MCP जुड़े हुए किसी भी MCP-कनेक्टेड एजेंट, जैसे Claude, में)। स्प्रेडशीट अपने-आप टेक्स्ट में बदल दी जाती है।
  3. सहायक हर पंक्ति को Didit स्कीमा में मैप करता है - शर्तें, वेलोसिटी विंडो, कार्रवाइयाँ - और कुछ भी बनाने से पहले मैपिंग दिखाता है, और जिन पंक्तियों का Didit में कोई समकक्ष नहीं है, उन्हें अलग से चिह्नित करता है।
  4. आपकी मंज़ूरी मिलने पर वह नियम TEST mode में बनाता है, उन्हें आपके अपने लेन-देन इतिहास पर बैकटेस्ट करता है, और बनाई गई / विफल / मैप न हो सकीं पंक्तियों की रिपोर्ट देता है।
  5. संख्याओं की समीक्षा करें और जो नियम सही लगें उन्हें सक्रिय करें, कंसोल से या PATCH {"mode": "ACTIVE"} के साथ।
प्रदाता का एक ऐसा एक्सपोर्ट:
इन नियमों में बदल जाता है:
CSV पंक्ति एक दिशा और एक मुद्रा बताती है, इसलिए नियम के दोनों हिस्सों में वे शामिल होते हैं: scope और conditions मूल्यांकन किए जा रहे लेन-देन को 10,000 से कम राशि के आउटबाउंड EUR ट्रांसफ़र तक सीमित करते हैं, और एग्रीगेशन फ़िल्टर 30-दिन की विंडो को उसी विषय से संबंधित आउटबाउंड EUR ट्रांसफ़र तक सीमित करते हैं। कच्चा amount केवल एक ही मुद्रा के भीतर तुलनीय है, इसलिए मुद्रा को ऊपर के अनुसार पिन रखें। मुद्रा-पार सीमा के लिए विंडो में हर लेन-देन के लिए सामान्यीकृत राशि होना ज़रूरी है। केवल preferred_currency_amount पर स्विच करने से उपलब्धता लागू नहीं होती: गायब ऐतिहासिक सामान्यीकृत राशियों को संख्यात्मक एग्रीगेशन में शून्य माना जा सकता है। max प्रविष्टि ही विंडो को 10,000 EUR से नीचे रखती है, क्योंकि एग्रीगेशन फ़िल्टर 10,000 से कम व्यक्त नहीं कर सकता - इसके लिए ऊपर बनाने का चरण वाला नोट देखें, जिसमें इसका ट्रेड-ऑफ़ समझाया गया है। स्कीमा जो चीज़ सटीक रूप से व्यक्त नहीं कर सकता, उसे चुपचाप अनुमानित करने के बजाय नियम के description में साफ़ शब्दों में लिखना बेहतर है।
किसी प्रदाता के नियम को कस्टम के रूप में दोबारा बनाने से पहले नियम लाइब्रेरी देखें: Didit सामान्य टाइपोलॉजी को कवर करने वाले 150+ प्रीसेट देता है (स्ट्रक्चरिंग, वेलोसिटी, प्रतिबंध एक्सपोज़र, डिवाइस पुनः उपयोग, क्रिप्टो जोखिम), और एक कॉल में प्रीसेट इंस्टॉल हो जाता है।

सत्यापन त्रुटियाँ जानबूझकर सटीक हैं

नियम बनाने और अपडेट करने वाले endpoints शर्तों, एग्रीगेशन और scope मानों को उसी से मिलाकर सत्यापित करते हैं जो नियम इंजन वास्तव में स्वीकार करता है: अज्ञात ऑपरेटर या मेट्रिक, गलत विंडो ("30days" की जगह "30d"), अमान्य scope दिशाएँ, बिना सूची के contains_any, बिना score के fuzzy_match, और बिना workflow_id के AWAITING_USER पर change_status, ये सभी इंडेक्स और समस्या का नाम लेने वाला 400 लौटाते हैं, बजाय ऐसा नियम सहेजने के जो चुपचाप कभी मेल ही न खाए। एजेंट और स्क्रिप्ट को त्रुटि बॉडी पढ़कर payload ठीक करना चाहिए। transaction_types, directions और action_types के अलावा अन्य scope keys सहेजे जाते हैं, लेकिन इंजन उन्हें अनदेखा करता है, ठीक वैसे ही जैसे Business Console उन्हें हमेशा से सहेजता रहा है।

अगले चरण

नियम और स्कोरिंग

पूरा नियम स्कीमा: फ़ील्ड, ऑपरेटर, वेलोसिटी विंडो, कार्रवाइयाँ।

नियम बनाने का API

अनुरोध और रिस्पॉन्स स्कीमा के साथ endpoint संदर्भ।

नियम लाइब्रेरी

150+ प्रीसेट कैटलॉग और उसके बंडल।

MCP अवलोकन

अपने Didit वर्कस्पेस से AI एजेंट को जोड़ें।
अंतिम संशोधन 7 नवंबर 2026