> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# सतत AML निगरानी: दैनिक पुनः स्क्रीनिंग

> Didit सत्यापित उपयोगकर्ताओं के लिए दैनिक AML पुनः स्क्रीनिंग और प्रतिबंधों पर webhook अलर्ट देता है। सतत अनुपालन $0.07/year से।

सतत निगरानी एक संपूर्ण AML कार्यक्रम का एक महत्वपूर्ण घटक है। यह सुनिश्चित करती है कि आपके ग्राहकों की समुचित जाँच-पड़ताल अप-टू-डेट रहे और आपको उन संभावित जोखिमों की पहचान करने में मदद करती है जो प्रारंभिक ऑनबोर्डिंग प्रक्रिया के बाद उत्पन्न हो सकते हैं। यह सुविधा उन सभी सत्रों के लिए स्वचालित रूप से शामिल है जहाँ AML जाँच की गई है, जिसके लिए किसी अतिरिक्त इंटीग्रेशन चरण की आवश्यकता नहीं होती है।

![दैनिक पुनः स्क्रीनिंग और webhook अलर्ट के साथ Didit सतत AML निगरानी डैशबोर्ड](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/aml-continuous-monitoring.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=8cf8c4ecef0f78953423a598defd2b2b)

### यह कैसे काम करता है

हमारा सतत निगरानी सिस्टम विभिन्न वॉचलिस्ट, प्रतिबंध सूचियों और प्रतिकूल मीडिया स्रोतों के विरुद्ध आपके सत्यापित उपयोगकर्ताओं की निरंतर जाँच करता है। यहाँ प्रक्रिया का विस्तृत विवरण दिया गया है:

1. **दैनिक स्वचालित जाँच**:
   * हमारा सिस्टम उन सभी सत्रों के लिए दैनिक स्वचालित जाँच चलाता है जो पहले स्वीकृत हो चुके हैं
   * प्रत्येक जाँच उपयोगकर्ता को वॉचलिस्ट और प्रतिबंध सूचियों के हमारे व्यापक डेटाबेस के विरुद्ध पुनः स्क्रीन करती है
   * सिस्टम किसी भी नए परिणाम की तुलना आपके कॉन्फ़िगर किए गए AML थ्रेशोल्ड से करता है

2. **थ्रेशोल्ड-आधारित अपडेट**:
   * यदि नए परिणाम मिलते हैं जो आपके कॉन्फ़िगर किए गए समीक्षा थ्रेशोल्ड से अधिक हैं, तो सत्र की स्थिति "समीक्षाधीन" में बदल जाती है
   * यदि नए परिणाम आपके अस्वीकृति थ्रेशोल्ड से अधिक हैं, तो सत्र की स्थिति स्वचालित रूप से "अस्वीकृत" में बदल जाती है
   * ये थ्रेशोल्ड वही हैं जिन्हें आपने अपने [Workflows](https://docs.didit.me/hi/console/workflows.md) में कॉन्फ़िगर किया है

3. **रीयल-टाइम नोटिफ़िकेशन**:
   * जब स्थिति में कोई बदलाव होता है, तो आपके एप्लिकेशन को एक webhook नोटिफ़िकेशन प्राप्त होता है
   * webhook payload में अपडेट की गई स्थिति और नए AML परिणामों के बारे में विस्तृत जानकारी शामिल होती है
   * ये नोटिफ़िकेशन हमारे मानक [webhook सिस्टम](https://docs.didit.me/hi/integration/webhooks.md) के समान प्रारूप का पालन करते हैं

4. **Business Console अपडेट**:
   * सभी परिवर्तन आपके Business Console में तुरंत दिखाई देते हैं
   * आपकी अनुपालन टीम नए AML परिणामों का निरीक्षण कर सकती है, विस्तृत निष्कर्षों की समीक्षा कर सकती है और उचित कार्रवाई कर सकती है
   * कंसोल सभी निगरानी गतिविधियों और स्थिति परिवर्तनों का एक संपूर्ण ऑडिट ट्रेल बनाए रखता है

### उपयोगकर्ताओं और व्यवसायों के लिए निगरानी सक्षम करना

आप सीधे कंसोल से सभी उपयोगकर्ताओं और व्यवसायों के लिए सतत निगरानी को चालू या बंद कर सकते हैं - जिसमें वे उपयोगकर्ता भी शामिल हैं जो कभी किसी AML जाँच से नहीं गुज़रे, जैसे कि इंपोर्ट किए गए उपयोगकर्ता।

1. अपने Business Console में **उपयोगकर्ता** (या **व्यवसाय**) खोलें, उन प्रोफ़ाइलों का चयन करें जिनकी आप निगरानी करना चाहते हैं, और **सतत AML निगरानी** पर क्लिक करें।
2. कुछ भी चलने से पहले संवाद लागत का अनुमान दिखाता है: कितनी प्रोफ़ाइलें चुनी गई हैं, कितनी प्रोफ़ाइलों को नई AML स्क्रीनिंग की आवश्यकता है, एकमुश्त स्क्रीनिंग लागत, और वार्षिक निगरानी लागत।
3. **निगरानी सक्षम करें** पर क्लिक करें। छोटे चयन तुरंत पूरे हो जाते हैं; बड़े चयन बैकग्राउंड में चलते हैं जबकि डायलॉग लाइव प्रगति दिखाता है।
4. जब रन पूरा हो जाता है, तो डायलॉग प्रति प्रोफ़ाइल परिणाम का विवरण देता है: सक्षम, स्क्रीन किए गए और सक्षम किए गए, पहले से सक्षम, या कारण के साथ छोड़ा गया (उदाहरण के लिए, ऐसी प्रोफ़ाइल जिसमें स्क्रीनिंग के लिए आवश्यक पूरा नाम, जन्म तिथि और देश नहीं है)।

जानने योग्य कुछ विवरण:

* **बिना AML स्क्रीनिंग वाली प्रोफ़ाइलों को पहले स्क्रीन किया जाता है।** Didit उनके लिए एक नया AML सत्यापन बनाता है (जो प्रोफ़ाइल के **सत्यापन** टैब में दिखाई देता है), जिसे एक नियमित AML स्क्रीनिंग के रूप में बिल किया जाता है। इसके बाद उस स्क्रीनिंग पर निगरानी सक्षम की जाती है।
* **प्रति प्रोफ़ाइल एक निगरानी की गई स्क्रीनिंग।** इसे सक्षम करने से प्रति उपयोगकर्ता या व्यवसाय ठीक एक निगरानी की गई AML स्क्रीनिंग रहती है, इसलिए जिस व्यक्ति ने कई बार सत्यापन किया है, उसकी केवल एक बार निगरानी की जाती है - और एक बार बिल किया जाता है। अक्षम करने पर प्रोफ़ाइल की सभी स्क्रीनिंग पर निगरानी बंद हो जाती है।
* **सूचियाँ एक नज़र में निगरानी दिखाती हैं।** **उपयोगकर्ता** और **व्यवसाय** दोनों सूचियों में एक **सतत निगरानी** कॉलम शामिल होता है; अगली वार्षिक बिलिंग तिथि देखने के लिए उस पर होवर करें।
* **सभी का चयन करें आपके फ़िल्टर के साथ काम करता है।** प्रत्येक पंक्ति के चयनित होने पर, कार्रवाई केवल लोड किए गए पेज पर ही नहीं, बल्कि आपके वर्तमान फ़िल्टर किए गए दृश्य पर लागू होती है।

### API के माध्यम से निगरानी सक्षम करना

वही ऑपरेशन आपकी API कुंजी के साथ आपके बैकएंड के लिए उपलब्ध है, इसलिए आपको किसी प्रोफ़ाइल को फिर से स्क्रीन करने या उसकी निगरानी बदलने के लिए कभी भी कंसोल खोलने की आवश्यकता नहीं होती है:

* उपयोगकर्ताओं के लिए [`POST /v3/users/aml-monitoring/`](https://docs.didit.me/hi/management-api/aml-monitoring/toggle-users)
* व्यवसायों के लिए [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/hi/management-api/aml-monitoring/toggle-businesses)
* किसी जॉब को पोल करने के लिए [`GET /v3/aml-monitoring/jobs/{job_id}/`](https://docs.didit.me/hi/management-api/aml-monitoring/get-job)

दोनों टॉगल endpoint आपके अपने पहचानकर्ताओं (`vendor_data_list`) और/या Didit आईडी (`didit_internal_id_list`) की सूची स्वीकार करते हैं, प्रति कॉल 1000 तक, और कंसोल के नियमों का पूरी तरह से पालन करते हैं: प्रति प्रोफ़ाइल एक मॉनिटर की गई स्क्रीनिंग, बिना स्क्रीनिंग वाली प्रोफ़ाइलों को पहले स्क्रीन किया जाता है, और अक्षम करने पर प्रोफ़ाइल की सभी स्क्रीनिंग में निगरानी बंद हो जाती है।

```bash theme={null}
# 1. Preview the cost. Nothing is written.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "estimate_only": true, "vendor_data_list": ["user-123", "user-456"]}'

# 2. Enable monitoring. 20 profiles or fewer complete inline (200);
#    larger selections return 202 and a job_id to poll.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'
```

रिस्पॉन्स में वही ब्रेकडाउन होता है जो कंसोल डायलॉग दिखाता है, साथ ही प्रति प्रोफ़ाइल एक `results` प्रविष्टि इसके परिणाम के साथ होती है: `enabled`, `screened_and_enabled`, `already_enabled`, `disabled`, या छोड़ने का कोई कारण जैसे कि `skipped_no_identity_data`। जो पहचानकर्ता किसी से मेल नहीं खाते हैं, वे `unmatched` के तहत वापस आते हैं। निगरानी को टॉगल करने से अपने आप कोई webhook जारी नहीं होता है; एक बार निगरानी चालू होने के बाद, पुनः स्क्रीनिंग सामान्य `status.updated` और `data.updated` इवेंट ट्रिगर करती है।

### यह प्रमाणित करना कि निगरानी चली थी

ऊपर दिए गए अलर्ट, गतिविधि प्रविष्टियाँ और webhook सभी **परिवर्तन** पर ट्रिगर होते हैं। एक वर्ष तक बिना किसी नए परिणाम के प्रतिदिन स्क्रीन की गई प्रोफ़ाइल इनमें से किसी को भी उत्पन्न नहीं करती है, इसलिए "कोई नई जानकारी नहीं" और "कुछ भी कभी नहीं चला" एक जैसे दिखते हैं - जो ऐसा उत्तर नहीं है जो किसी ऑडिट में मान्य ठहरे। तीन माध्यम स्वयं इन रनों को रिकॉर्ड करते हैं।

**1. अंतिम स्क्रीनिंग तिथि, AML रिपोर्ट पर।** `last_ongoing_screening_at` प्रत्येक पूर्ण रन पर अपडेट होता है, चाहे उसमें बदलाव हुआ हो या नहीं, जो `/v2/` और `/v3/` सत्र निर्णयों और स्टैंडअलोन AML रिपोर्ट पर उपलब्ध होता है। इसके साथ मौजूद `last_ongoing_screening_datasets_updated_at` प्रदाता द्वारा उस रन के लिए रिपोर्ट किया गया सबसे हालिया AML डेटासेट अपडेट है। दोनों में से किसी का भी कभी अनुमान नहीं लगाया जाता है: `null` का अर्थ क्रमशः "कभी पुनः स्क्रीन नहीं किया गया" और "कोई डेटासेट तिथि रिपोर्ट नहीं की गई" है, न कि "अज्ञात है इसलिए यहाँ एक संभावित तिथि दी गई है"। `next_ongoing_monitoring_bill_date` को स्क्रीनिंग तिथि के रूप में न समझें - यह एक बिलिंग तिथि है।

**2. स्क्रीनिंग इतिहास, प्रति विषय।** `GET /v1/session/{session_id}/aml-screening-history/` उस सत्र की AML जाँच के लिए प्रत्येक पूर्ण किए गए रन को लौटाता है, नवीनतम पहले, जिसमें वे रन भी शामिल हैं जिनका परिणाम `NO_CHANGE` था। जब किसी ग्राफ़ वर्कफ़्लो में एक से अधिक AML नोड हों, तो `?node_id=` जोड़ें।

```bash theme={null}
curl https://verification.didit.me/v1/session/SESSION_ID/aml-screening-history/ \
  -H "x-api-key: YOUR_API_KEY"
```

```json theme={null}
{
  "count": 2,
  "results": [
    {
      "uuid": "0d1c...",
      "completed_at": "2026-09-12T04:03:11Z",
      "started_at": "2026-09-12T04:00:02Z",
      "outcome": "NO_CHANGE",
      "trigger": "ONGOING_MONITORING",
      "status": "Approved",
      "score": 0,
      "total_hits": 0,
      "dataset_freshness": null
    }
  ]
}
```

| फ़ील्ड | अर्थ |
| - | - |
| `outcome` | `NO_CHANGE` — रन पूरा हुआ और परिणाम में कोई बदलाव नहीं हुआ। `CHANGED` — रन पूरा हुआ और स्कोर, स्थिति या हिट्स बदल गए। `FAILED` — प्रदाता ने इस विषय के लिए कोई प्रयोग करने योग्य उत्तर नहीं लौटाया, इसलिए कुछ भी स्क्रीन नहीं किया गया और कुछ भी नहीं बदला गया। कवरेज में अंतराल को छिपाने के बजाय रिकॉर्ड किया जाता है। |
| `completed_at` / `started_at` | इस विषय की स्क्रीनिंग कब समाप्त हुई, और जिस बैच से यह संबंधित था वह कब शुरू हुआ। |
| `status` / `score` / `total_hits` | रन ने चेक को जिस स्थिति में छोड़ा। |
| `dataset_freshness` | उस रन के लिए प्रदाता की सूचियाँ कितनी अद्यतन थीं, या जब डेटासेट की कोई तिथि उपलब्ध नहीं थी तब `null`। |

**3. एक्सपोर्ट करने योग्य साक्ष्य।** `GET /v1/session/{session_id}/aml-screening-history/export/` समान इतिहास को एक CSV फ़ाइल के रूप में स्ट्रीम करता है — प्रति पूर्ण स्क्रीनिंग एक पंक्ति, जहाँ प्रदाता ने रिपोर्ट किया हो वहाँ प्रति स्रोत परिवार डेटासेट अपडेट तिथि के साथ और जहाँ नहीं किया गया वहाँ एक खाली सेल। यह फ़ाइल वही है जो एक अनुपालन टीम किसी ऑडिटर को सौंपती है। Business Console AML परिणाम के बगल में समान सूची और समान एक्सपोर्ट प्रदर्शित करता है, ताकि समीक्षकों को इसे तैयार करने के लिए API एक्सेस की आवश्यकता न पड़े।

> [!NOTE]
>
> **उपलब्धता की सीमाएँ, स्पष्ट रूप से कही गई हैं।** इतिहास इस सुविधा के लाइव होने के क्षण से आगे रिकॉर्ड किया जाता है; पिछली स्क्रीनिंग का पुनर्निर्माण नहीं किया जाता है और वे बस अनुपस्थित रहती हैं। रन कॉन्फ़िगर की गई डेटा प्रतिधारण विंडो (डिफ़ॉल्ट रूप से दो वर्ष) के लिए रखे जाते हैं। डेटासेट की ताज़गी प्रदाता द्वारा आपके एनवायरनमेंट के लिए डेटासेट तिथियाँ प्रकाशित करने पर निर्भर करती है — जहाँ ऐसा नहीं होता है, प्रत्येक डेटासेट फ़ील्ड `null` दिखाता है और `GET /v1/aml/dataset-freshness/`, `availability: "not_configured"` रिपोर्ट करता है। अनुपस्थित तिथि को कभी भी किसी स्थानापन्न से नहीं बदला जाता है।

### सतत निगरानी के लाभ

1. **सतत अनुपालन**: बिना किसी अतिरिक्त सेटअप के AML/KYC विनियमों का निरंतर पालन सुनिश्चित करें।
2. **जोखिम शमन**: स्वचालित निगरानी के माध्यम से उभरते जोखिमों की तुरंत पहचान करें और उनका समाधान करें।
3. **परिचालन दक्षता**: बिना किसी अतिरिक्त इंटीग्रेशन कार्य के अधिक समय लेने वाली मैन्युअल रीस्क्रीनिंग प्रक्रियाओं को स्वचालित करें।
4. **संवर्धित ड्यू डिलिजेंस**: ग्राहक प्रोफ़ाइलों को स्वचालित रूप से अप-टू-डेट बनाए रखें।
5. **नियामक सहायता**: नियामकों के समक्ष सतत अनुपालन प्रयासों को आसानी से प्रदर्शित करें।
6. **ज़ीरो-टच इंटीग्रेशन**: बिना किसी अतिरिक्त डेवलपमेंट कार्य के सतत निगरानी का लाभ उठाएं।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.