लेन-देन रिस्पॉन्स स्कीमा: KYT payload संदर्भ

यह पेज POST /v3/transactions/ और GET /v3/transactions/{transaction_id}/ द्वारा लौटाए गए पूरे payload का दस्तावेज़ है। दोनों endpoint एक ही TransactionDetail ऑब्जेक्ट लौटाते हैं। API संदर्भ में फ़ील्ड-दर-फ़ील्ड स्कीमा दिया गया है, और यह पेज उसे चरण-दर-चरण समझाता है।

शीर्ष-स्तरीय संरचना

{
  "uuid": "abcdef12-3456-4890-abcd-ef1234567890",
  "environment": "live",
  "transaction_number": 4123,
  "txn_id": "tx-0001",
  "txn_date": "2026-04-16T12:00:00Z",
  "zone_id": "Europe/Madrid",
  "transaction_type": "finance",
  "action_type": "withdrawal",
  "direction": "OUTBOUND",
  "status": "IN_REVIEW",
  "source": "LIVE",
  "amount": "12500",
  "currency": "EUR",
  "currency_type": "fiat",
  "amount_in_default_currency": null,
  "default_currency_code": null,
  "preferred_currency_amount": "13520.75",
  "preferred_currency_code": "USD",
  "payment_details": "Withdrawal to bank account",
  "payment_txn_id": null,
  "score": 65,
  "severity": "MEDIUM",
  "decision_reason_code": "rule_score_threshold",
  "decision_reason_label": "Score above review threshold",
  "vendor_data": "user-42",
  "metadata": { "subject": { ... }, "counterparty": { ... } },
  "props": { "order_id": "ORD-7891" },
  "tags": [ ... ],
  "parties": [ ... ],
  "payment_methods": [ ... ],
  "documents": [ ... ],
  "activities": [ ... ],
  "alerts": [],
  "rule_runs": [ ... ],
  "provider_results": [ ... ],
  "travel_rule": { ... } | null,
  "network_snapshot": { ... } | null,
  "remediation": { ... } | null,
  "action_required": { ... } | null,
  "cost_breakdown": { ... } | null
}

दो पहचानकर्ता एक ही लेन-देन का वर्णन करते हैं। uuid Didit का स्थिर पहचानकर्ता है और GET /v3/transactions/{transaction_id}/ अपने पाथ में इसी की अपेक्षा करता है। txn_id वह transaction_id है जो आपने बनाते समय दिया था। transaction_number एप्लिकेशन-स्तरीय अनुक्रमिक संख्या है, जो कंसोल में दिखाई देती है। आपने जो विषय और प्रतिपक्ष सबमिट किए थे, वे शीर्ष-स्तरीय कीज़ के रूप में वापस नहीं आते। वे parties ऐरे की प्रविष्टियाँ हैं, जिन्हें role से पहचाना जाता है। शीर्ष स्तर पर मौजूद vendor_data आवेदक के vendor_data की सुविधा के लिए बनाई गई प्रति है।

मुख्य फ़ील्ड

वित्तीय फ़ील्ड

amount / currency: लेन-देन की राशि जैसी सबमिट की गई थी। amount एक दशमलव स्ट्रिंग है, जिसके अंत में आने वाले शून्य हटा दिए जाते हैं ("1500", "0.5"), और दशमलव के बाद अधिकतम 18 स्थान हो सकते हैं।
currency_type: fiat या crypto, जैसा currency_kind में सबमिट किया गया था। छोड़े जाने पर null।
amount_in_default_currency / default_currency_code: वह पहले से परिवर्तित राशि जो आपने अनुरोध में दी थी, जो वापस भेजी जाती है। यदि आपने यह नहीं भेजी, तो null।
preferred_currency_amount / preferred_currency_code: amount का आपकी एप्लिकेशन की पसंदीदा मुद्रा में परिवर्तित मान। जब currency के लिए कोई विनिमय दर उपलब्ध नहीं होती और आपने amount_in_default_currency नहीं दिया, तो null।
payment_details / payment_txn_id: अनुरोध से मिला मुक्त-पाठ भुगतान संदर्भ और बाहरी भुगतान संदर्भ (उदाहरण के लिए ब्लॉकचेन लेन-देन हैश)।

स्थिति फ़ील्ड

status: APPROVED, IN_REVIEW, DECLINED, AWAITING_USER। लेन-देन APPROVED स्थिति के साथ बनाए जाते हैं; नियम इन्हें सिंक्रोनस रूप से बदल सकते हैं।
score: नियमों द्वारा जोड़ा गया पूर्णांक जोखिम स्कोर। अधिक मान का अर्थ है अधिक जोखिम।
severity: UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL, या null, जब तक कोई नियम या प्रदाता इसे सेट नहीं करता।
decision_reason_code / decision_reason_label: मौजूदा स्थिति का संरचित और मानव-पठनीय कारण।
environment - live या sandbox, उस एप्लिकेशन से जो लेन-देन का स्वामी है। sandbox लेन-देन संग्रहीत तो होता है, पर उसका मूल्यांकन कभी नहीं होता, इसलिए उसके खाली rule_runs का अर्थ है “मूल्यांकन नहीं हुआ”, न कि “कुछ भी मेल नहीं खाया”। देखें सैंडबॉक्स में लेन-देन निगरानी।
source - LIVE उन लेन-देनों के लिए जो API या SDK से सबमिट किए गए हों, IMPORTED उन लेन-देनों के लिए जो कंसोल CSV इंपोर्ट से लोड किए गए हों।

पक्ष

लेन-देन का हर पक्ष parties में एक प्रविष्टि होती है। बनाने वाला endpoint विषय को APPLICANT और वैकल्पिक प्रतिपक्ष को COUNTERPARTY के रूप में दर्ज करता है। role enum में REMITTER और BENEFICIARY भी शामिल हैं। सभी प्रविष्टियों का एक ही ढाँचा होता है।

"parties": [
  {
    "uuid": "b1111111-2222-4333-8444-555555555555",
    "role": "APPLICANT",
    "entity_type": "individual",
    "kind": "USER",
    "vendor_data": "user-42",
    "full_name": "John Doe",
    "first_name": "John",
    "last_name": "Doe",
    "country_code": "USA",
    "dob": "1990-01-01",
    "address": { "line_1": "...", "city": "...", "country": "USA" },
    "institution_info": { "name": "...", "country_code": "..." },
    "device": {
      "fingerprint": "...",
      "persistent_device_id": "...",
      "user_agent": "...",
      "browser_family": "Chrome",
      "browser_version": "131.0",
      "platform": "web",
      "os_family": "Windows",
      "os_version": "10.0",
      "accept_language": "en-US,en;q=0.9",
      "session_id": "...",
      "session_age_ms": 84000,
      "metadata": {
        "accept_language": "en-US,en;q=0.9",
        "session_id": "...",
        "session_age_ms": 84000
      },
      "network_context": {
        "ip_address": "203.0.113.5",
        "ip_country": "United States",
        "ip_country_code": "US",
        "ip_state": "California",
        "ip_city": "San Francisco",
        "latitude": 37.7749,
        "longitude": -122.4194,
        "isp": "Example ISP",
        "organization": "Example Org",
        "is_vpn_or_tor": false,
        "is_data_center": false,
        "time_zone": "America/Los_Angeles",
        "time_zone_offset": "-0700",
        "asn_number": 64496,
        "asn_organization": "Example ISP",
        "connection_type": "isp",
        "carrier": null,
        "proxy_type": null
      }
    },
    "external_party_snapshot": null
  },
  {
    "uuid": "c2222222-3333-4444-8555-666666666666",
    "role": "COUNTERPARTY",
    "entity_type": "company",
    "kind": "EXTERNAL",
    "vendor_data": null,
    "full_name": "Acme Supplier",
    "first_name": null,
    "last_name": null,
    "country_code": "GBR",
    "dob": null,
    "address": {},
    "institution_info": {},
    "device": {},
    "external_party_snapshot": { "full_name": "Acme Supplier", "country": "GBR", "...": "..." }
  }
]

role: APPLICANT, COUNTERPARTY, REMITTER, BENEFICIARY। विषय खोजने के लिए इस पर फ़िल्टर करें।
entity_type: individual, company, external, unhostedWallet, जैसा सबमिट किया गया था।
kind: USER या BUSINESS, जब पक्ष vendor_data के माध्यम से किसी Didit उपयोगकर्ता या व्यवसाय से जुड़ा हो; अन्यथा EXTERNAL।
country_code / dob: सबमिट किए गए address.country और date_of_birth से।
address / institution_info: सबमिट की गई वस्तुएँ जैसी थीं वैसी; छोड़े जाने पर {}।
external_party_snapshot: EXTERNAL पक्षों के लिए पक्ष डेटा की फ़्रीज़ की गई प्रति; null, जब पक्ष किसी Didit उपयोगकर्ता या व्यवसाय से जुड़ा हो।

`device`

device वह device_context है जो आपने उस पक्ष के लिए सबमिट किया था, जिसे snake_case में सामान्यीकृत किया गया है, साथ ही सर्वर-साइड IP एनरिचमेंट। यदि अनुरोध में कोई डिवाइस संदर्भ नहीं था, तो यह {} होता है, इसलिए हर कुंजी को वैकल्पिक मानें।

कुंजी	विवरण
`fingerprint`, `persistent_device_id`	सबमिट किए गए डिवाइस पहचानकर्ता।
`user_agent`, `browser_family`, `browser_version`, `platform`, `os_family`, `os_version`	सबमिट किए गए ब्राउज़र और OS के गुण। `browser_family` और `platform` कभी `user_agent` से व्युत्पन्न नहीं किए जाते।
`accept_language`, `session_id`, `session_age_ms`	सबमिट किए गए सत्र के गुण। इन्हें उन्हीं नामों से `device.metadata` में भी दर्ज किया जाता है, और SDK पथ यहीं उन्हें संग्रहीत करता है।
`metadata`	तब मौजूद, जब अनुरोध में `metadata` ऑब्जेक्ट या तीनों सत्र गुणों में से कोई हो।
`network_context`	नेटवर्क संदर्भ, नीचे देखें। जब कोई IP या नेटवर्क डेटा सबमिट नहीं हुआ हो, तब अनुपस्थित।

कोई अलग एनरिचमेंट ऑब्जेक्ट नहीं है। जब पक्ष ने सार्वजनिक network_context.ip_address दिया हो, तो Didit उसे इनलाइन रिज़ॉल्व करता है और एनरिच किए गए फ़ील्ड को उसी network_context ऑब्जेक्ट में लिखता है, और केवल वही कुंजियाँ भरता है जो आपने नहीं दीं। जिन कुंजियों के लिए रिज़ॉल्वर ने खाली मान लौटाया, उन्हें छोड़ दिया जाता है। इसलिए पूरी तरह एनरिच किए गए network_context में चार सबमिट की गई कुंजियाँ (ip_address, ip_country_code, latitude, longitude) होती हैं, साथ में वे सभी जो रिज़ॉल्व हुईं: ip_country, ip_state, ip_city, isp, organization, is_vpn_or_tor, is_data_center, time_zone, time_zone_offset, asn_number, asn_organization, connection_type, carrier और proxy_type। सफल रिज़ॉल्यूशन के बाद is_vpn_or_tor और is_data_center हमेशा मौजूद रहते हैं। एनरिचमेंट छोड़ दिया जाता है, और network_context जैसा सबमिट किया गया था वैसा ही लौटाया जाता है, जब IP गायब हो या रूट न हो सकने योग्य हो, जब एप्लिकेशन सैंडबॉक्स में हो, या जब रिज़ॉल्यूशन विफल रहा हो। ip_country_code तब ISO 3166-1 alpha-2 कोड होता है जब Didit ने उसे रिज़ॉल्व किया हो, और अन्यथा वही होता है जो आपने सबमिट किया था; नियम की शर्तें तुलना से पहले दोनों रूपों को सामान्यीकृत करती हैं।

भुगतान विधियाँ

"payment_methods": [
  {
    "uuid": "...",
    "payment_method_type": "bank_account",
    "label": null,
    "fingerprint": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "account_id": "DE89370400440532013000",
    "issuing_country": "DE",
    "owner_kind": "USER",
    "vendor_data": "user-42",
    "owner_name": "John Doe",
    "institution_info": {},
    "details": { "method_type": "bank_account", "account_id": "DE89370400440532013000", "issuing_country": "DE" },
    "external_owner_snapshot": null,
    "role": "SOURCE"
  }
]

role: SOURCE, DESTINATION, FUNDING, BENEFICIARY। बनाने वाला endpoint direction के आधार पर SOURCE / DESTINATION असाइन करता है: बाहर जाने वाले लेन-देन में विषय की विधि SOURCE होती है और प्रतिपक्ष की DESTINATION; अंदर आने वाले लेन-देन में यह उलट होता है।
payment_method_type: bank_card, bank_account, e_wallet, crypto_wallet, unhosted_wallet, other।
fingerprint: type:account_id:issuing_country पर SHA-256, जो लेन-देनों में स्थिर रहता है, ताकि एक ही साधन के दोबारा उपयोग को जोड़ा जा सके। कोई account_id सबमिट न होने पर null।
owner_kind / vendor_data / owner_name: साधन का स्वामी कौन है, पक्षों वाले उसी USER / BUSINESS / EXTERNAL नियम के अनुसार।
details: सबमिट किया गया कच्चा payment_method ऑब्जेक्ट।

नियम रन

"rule_runs": [
  {
    "uuid": "...",
    "rule": "f6a7b8c9-0123-4def-b012-3456789abcde",
    "rule_title": "High-value outbound",
    "rule_description": null,
    "rule_category": "finance",
    "matched": true,
    "is_test": false,
    "mode": "ACTIVE",
    "severity": "MEDIUM",
    "score_delta": 30,
    "status_target": null,
    "action_summary": "score +30",
    "metadata": {
      "scope_match": true,
      "conditions": [
        {
          "field": "amount",
          "operator": "gt",
          "expected_value": "10000",
          "current_value": "12500",
          "matched": true,
          "group_index": null,
          "group_logic": "AND",
          "field_source": null
        }
      ],
      "aggregations": []
    },
    "created_at": "2026-04-16T12:00:01Z"
  },
  {
    "uuid": "...",
    "rule": "...",
    "rule_title": "High-risk jurisdiction counterparty",
    "rule_description": null,
    "rule_category": "finance",
    "matched": true,
    "is_test": false,
    "mode": "ACTIVE",
    "severity": "HIGH",
    "score_delta": 35,
    "status_target": "IN_REVIEW",
    "action_summary": "score +35; change_status:IN_REVIEW; add_tag:high_risk_country",
    "metadata": { "scope_match": true, "conditions": [ ... ], "aggregations": [] },
    "created_at": "2026-04-16T12:00:01Z"
  }
]

rule: चले हुए नियम का UUID; rule_title, rule_description, rule_category उसी से कॉपी किए जाते हैं।
matched: रन तभी दर्ज होता है जब नियम की शर्तें मेल खाएँ, इसलिए लाइव मूल्यांकन में हमेशा matched: true होता है। जो नियम बिना मेल के मूल्यांकित हुए, उनकी कोई प्रविष्टि नहीं बनती। डेमो डेटा में matched: false पंक्तियाँ हो सकती हैं।
is_test / mode: जब नियम टेस्ट मोड में चला हो तो true और TEST; टेस्ट रन दर्ज होता है, पर उसका status, score या severity पर कोई प्रभाव नहीं पड़ता।
score_delta / status_target / severity: इस रन ने क्या योगदान दिया। status_target तब सेट होता है जब कोई change_status कार्रवाई चली हो, या जब जोड़ा गया स्कोर एक थ्रेशोल्ड पार कर गया हो।
action_summary: नियम द्वारा चलाई गई कार्रवाइयों का स्ट्रिंग सारांश, ; से जुड़ा (score +30, change_status:IN_REVIEW, add_tag:<name>, add_note, add_to_list, open_case); जब नियम ने कोई कार्रवाई नहीं चलाई, तो null।
metadata: मूल्यांकन का विवरण: scope_match, साथ में conditions[] और aggregations[]। दोनों सूचियाँ अलग-अलग मान कुंजियों का उपयोग करती हैं:
- conditions[]: हर शर्त के लिए एक प्रविष्टि, जिसमें field, operator, expected_value, लेन-देन से पढ़ा गया current_value, matched, group_index और group_logic होते हैं। लेन-देन नियम रन पर field_source हमेशा null होता है; इसे केवल मॉनिटरिंग इवेंट के लिए वर्गीकृत किया जाता है।
- aggregations[]: हर velocity / count / sum एग्रीगेशन के लिए एक प्रविष्टि, जिसमें metric, field, operator, expected_value, वह computed_value जिस तक एग्रीगेट का परिणाम पहुँचा, window, filters, matched और sample_references होते हैं। जो एग्रीगेशन केवल असिंक्रोनस रूप से गणना किए जा सकते थे, उनमें computed_value: null और deferred: true होता है।

अलर्ट

alerts आज हमेशा एक खाली एरे होता है। खुला अलर्ट एक रोका गया लेन-देन है, इसलिए इसके बजाय status (IN_REVIEW या AWAITING_USER) पढ़ें। देखें अलर्ट।

गतिविधियाँ

लेन-देन का गतिविधि लॉग: निर्माण, नोट, मैन्युअल समीक्षाएँ और स्थिति परिवर्तन।

"activities": [
  {
    "uuid": "...",
    "activity_type": "TRANSACTION_CREATED",
    "source": "TRANSACTION",
    "status": "APPROVED",
    "title": "withdrawal",
    "description": null,
    "metadata": { "action_type": "withdrawal", "direction": "OUTBOUND", "amount": "12500", "currency": "EUR" },
    "occurred_at": "2026-04-16T12:00:00Z"
  }
]

विश्लेषक के नोट यहाँ TRANSACTION_NOTE_ADDED प्रविष्टियों के रूप में दिखते हैं; इसके लिए कोई अलग notes एरे नहीं है।

दस्तावेज़

कंसोल से लेन-देन में जोड़ी गई फ़ाइलें। कोई न होने पर []।

"documents": [
  {
    "uuid": "...",
    "label": "Invoice",
    "note": null,
    "uploaded_by": "...",
    "created_at": "2026-04-16T12:05:00Z",
    "files": [
      { "uuid": "...", "file_url": "https://...", "original_filename": "invoice.pdf", "file_size": 48213 }
    ]
  }
]

file_url एक अल्पकालिक साइन्ड URL है; जब ज़रूरत हो तब इसे प्राप्त करें, इसे स्टोर न करें।

प्रदाता परिणाम

बाहरी प्रदाताओं के आउटपुट (लेन-देन हैश स्क्रीनिंग, वॉलेट स्क्रीनिंग, फ़िएट निगरानी, प्रतिबंध स्क्रीनिंग)।

"provider_results": [
  {
    "uuid": "...",
    "result_type": "TRANSACTION_SCREENING",
    "provider": "merklescience",
    "status": "SCREENED",
    "severity": "HIGH",
    "score": 82,
    "summary": "Merkle Science risk: High (4/5). Dominant risk: stolen_funds. Driven by: 50% direct incoming exposure to Theft / Hack (Stolen Funds)",
    "payload": {
      "provider": "merklescience",
      "screening_type": "TRANSACTION_SCREENING",
      "transaction_hash": "0x...",
      "wallet_address": null,
      "blockchain": "ETH",
      "block_timestamp": "2026-04-01T00:07:11Z",
      "total_value_usd": 2942.31,
      "fee_usd": 0.09,
      "transaction_flows": [
        {
          "flow_type": "token",
          "from_address": "0x...",
          "to_address": "0x...",
          "amount": 72.83039728,
          "amount_usd": 235.97,
          "currency": "UNI",
          "token_name": "Uniswap",
          "token_address": "0x1f9840a85d5af5bf1d1762f925bdaddc4201f984",
          "transaction_hash": "0x...",
          "block_timestamp": "2026-04-01T00:07:11Z",
          "index": 460,
          "success": true,
          "metadata": {
            "provider": "blockscout",
            "token_type": "ERC-20",
            "token_icon_url": "https://...",
            "token_reputation": "ok",
            "token_holders_count": "410093",
            "from": {
              "label": "ravaga.eth",
              "tags": [{ "name": "Beacon Depositor", "type": "generic" }]
            },
            "to": {
              "label": "AirSwap: Spender",
              "is_contract": true,
              "is_verified": true
            }
          }
        }
      ],
      "source_of_funds": [
        {
          "category": "stolen_funds",
          "entity_name": "Stolen Funds",
          "entity_type": "Theft",
          "entity_subtype": "Hack",
          "exposure_direction": "incoming",
          "exposure_type": "direct",
          "is_direct": true,
          "amount_usd": 1471.16,
          "percentage": 50,
          "country": ""
        }
      ],
      "destination_of_funds": [],
      "counterparty_connections": [],
      "sanctions_hit": false,
      "risk_factors": [
        {
          "source": "exposure",
          "category": "stolen_funds",
          "label": "Theft / Hack",
          "entity_name": "Stolen Funds",
          "direction": "incoming",
          "exposure_type": "direct",
          "amount_usd": 1471.16,
          "percentage": 50,
          "is_high_risk": true,
          "description": "50% direct incoming exposure to Theft / Hack (Stolen Funds)"
        }
      ],
      "raw_response": { "...": "provider-specific details" }
    },
    "created_at": "2026-04-16T12:00:02Z"
  }
]

result_type: FIAT_MONITORING, WALLET_SCREENING, TRANSACTION_SCREENING, TRAVEL_RULE, NETWORK_GRAPH, CUSTOM. payload.risk_factors उस score की रैंक्ड व्याख्या है: यानी निर्णय किन कारकों से बना, उच्च-जोखिम वाले ड्राइवर पहले, फिर स्थानांतरित मूल्य के अनुसार। उच्च score के साथ कोई is_high_risk प्रविष्टि न होना इसका अर्थ है कि प्रदाता ने प्रतिबंध या संबद्ध इकाई से मिलान की सूचना दिए बिना, अपने एक्सपोज़र मॉडल के आधार पर इकाई को ग्रेड किया; summary इसे स्पष्ट रूप से बताता है। फ़ील्ड-दर-फ़ील्ड संदर्भ: जोखिम कारक। इस फ़ील्ड से पहले स्क्रीन किए गए परिणामों में यह कुंजी नहीं होती। क्रिप्टो लेन-देन-हैश स्क्रीनिंग के लिए, जब ऑन-चेन एनरिचमेंट उपलब्ध होता है, तो transaction_flows भरा जाता है। यह चेन गतिविधि को सामान्यीकृत करता है, ताकि कंसोल एक ही रिस्पॉन्स पेलोड से लेन-देन का अवलोकन और विज़ुअलाइज़ेशन ग्राफ़ दोनों दिखा सके। समर्थित एनरिचमेंट स्रोत:

EVM चेन मुख्य लेन-देन, इंटरनल कॉल और टोकन ट्रांसफ़र को सामान्यीकृत करने के लिए Blockscout का उपयोग करती हैं।
Bitcoin लेन-देन के इनपुट और आउटपुट को सामान्यीकृत करने के लिए mempool.space का उपयोग करता है।
Solana native SOL ट्रांसफ़र, SPL टोकन ट्रांसफ़र और उपलब्ध NFT इवेंट संदर्भ को सामान्यीकृत करने के लिए Helius का उपयोग करता है।

हर transaction_flows[] आइटम में स्थिर सामान्यीकृत फ़ील्ड (flow_type, from_address, to_address, amount, amount_usd, currency, token_name, token_address, transaction_hash, block_timestamp, index, success) और प्रदाता-विशिष्ट metadata शामिल होते हैं। सामान्य metadata उदाहरण:

{
  "provider": "blockscout",
  "decoded_method_call": "swap(string aggregatorId, address tokenFrom, uint256 amount, bytes data)",
  "block_number": 23141214,
  "gas_used": "171843",
  "fee_native": 0.000342317619518133,
  "token_icon_url": "https://...",
  "token_reputation": "ok"
}

{
  "provider": "mempool",
  "role": "input",
  "previous_txid": "4c0c...",
  "previous_vout": 0,
  "scriptpubkey_type": "v0_p2wpkh",
  "fee_btc": 0.00000322,
  "block_height": 943130
}

{
  "provider": "helius",
  "source": "MAGIC_EDEN",
  "type": "NFT_BID",
  "description": "Wallet bid 2.5 SOL on an NFT.",
  "slot": 136658192,
  "fee_sol": 0.000005,
  "nft_event": {
    "type": "NFT_BID",
    "source": "MAGIC_EDEN",
    "nft_mints": ["3bUW..."]
  }
}

metadata एडिटिव और प्रदाता-विशिष्ट है। ऐसे क्रिटिकल इंटीग्रेशन न बनाएँ जिनमें हर चेन पर हर key का मौजूद होना ज़रूरी हो।

Travel Rule

लेन-देन में कोई Travel Rule ट्रांसफ़र या जाँच न होने पर null। यह तब भरा जाता है जब आप travel_rule_details सबमिट करते हैं, और तब भी जब ऐप्लिकेशन के लिए Travel Rule सक्षम हो और लेन-देन transaction_category: "travelRule" के साथ बनाया गया हो: तब Didit स्वयं एक्सचेंज शुरू करता है, travel_rule_details के साथ या उसके बिना, और उसकी status यहाँ रिपोर्ट करता है। भेजे गए अनुरोध के बजाय इस फ़ील्ड को पढ़ें। इनबाउंड ट्रांसफ़र पर, काउंटरपार्टी का originator_data और beneficiary_data तब तक मास्क्ड रहते हैं (data_masked: true) जब तक वॉलेट स्वामित्व की पुष्टि नहीं होती (मास्क्ड काउंटरपार्टी डेटा देखें)।

"travel_rule": {
  "uuid": "...",
  "status": "COMPLETED",
  "required": true,
  "protocol": "TRP",
  "obligations_count": 2,
  "originator_data": { "name": "...", "wallet_address": "..." },
  "beneficiary_data": { "name": "...", "wallet_address": "..." },
  "metadata": {},
  "direction": "OUTBOUND",
  "rail": "TRP",
  "counterparty_vasp": null,
  "delivery": {
    "kind": "SEND",
    "status": "DELIVERED",
    "rail": "TRP",
    "attempts": 1,
    "last_error": "",
    "next_attempt_at": null,
    "delivered_at": "..."
  },
  "discovery": [ ... ],
  "reason": "",
  "next_actions": []
}

direction, rail, counterparty_vasp, delivery, discovery, reason और next_actions की संरचना वही है जो ट्रांसफ़र endpoint पर है। reason और next_actions बताते हैं कि COUNTERPARTY_VASP_NOT_FOUND या COUNTERPARTY_VASP_NOT_REACHABLE ट्रांसफ़र क्यों अटका है और उसे आगे क्या बढ़ाता है; किसी अन्य स्थिति के लिए ये "" और [] होते हैं: देखें ट्रांसफ़र क्यों अटका है। GET /v3/transactions/ की हर पंक्ति में यही ब्लॉक होता है। Travel Rule देखें।

नेटवर्क स्नैपशॉट

संग्रहीत ग्राफ़ स्वयं, उसका संदर्भ नहीं। यह दो स्रोतों में से किसी एक से आता है:

आपके द्वारा लेन-देन के साथ सबमिट किया गया network_snapshot, या
AML वॉलेट स्क्रीनिंग सफल होने पर Didit द्वारा बनाया गया ग्राफ़, क्रिप्टो लेन-देन के लिए, भले ही अनुरोध में कोई network_snapshot न हो। स्क्रीनिंग से बना ग्राफ़ सबमिट किए गए ग्राफ़ की जगह ले लेता है, और एसिंक्रोनस री-स्क्रीन उसे ताज़ा करता है।

दोनों में से कोई न होने पर null:

"network_snapshot": {
  "uuid": "...",
  "nodes": [ ... ],
  "edges": [ ... ],
  "metrics": { }
}

कंसोल का लेन-देन विवरण पेज वही ग्राफ़ दिखाता है।

टैग, metadata, props

tags[]: संलग्न टैग (नियम की कार्रवाई द्वारा या विश्लेषक द्वारा): { "uuid", "name", "color", "description", "source" }, जहाँ source प्रीसेट टैग के लिए didit और आपके अपने टैग के लिए custom होता है।
metadata: बनाते समय जैसे आपने सबमिट किए, वैसे subject और counterparty payloads का स्नैपशॉट, उन्हीं दो कुंजियों के अंतर्गत।
props: बनाते समय आपने जो custom_properties दिए। हर key को नियम शर्तों में custom_values.<key> के रूप में संदर्भित किया जा सकता है।

सुधारात्मक कार्रवाई

जब कोई नियम AWAITING_USER ट्रिगर करता है, तो Didit लिंक्ड सत्यापन सत्र बनाता है और उसे दो फ़ील्ड में लौटाता है:

remediation: लिंक्ड सत्र: { "session_id", "session_token", "url", "status" }। लेन-देन के पूरे जीवनकाल में भरा रहता है, ताकि आप देख सकें कि उपयोगकर्ता की कार्रवाई कैसे समाप्त हुई।
action_required: वह कार्रवाई जो उपयोगकर्ता को अभी करनी है, या कुछ भी लंबित न होने पर null: { "type": "verification_session", "url", "session_id", "session_token", "status" }। उपयोगकर्ता को url पर रीडायरेक्ट करें, या session_token को किसी Didit SDK को दें। Travel Rule वॉलेट-स्वामित्व कार्रवाइयाँ { "type": "wallet_ownership", "url", "widget_session_id", "expires_at" } का उपयोग करती हैं और दोनों लागू हो सकने पर प्राथमिकता लेती हैं। जब वॉलेट-स्वामित्व कार्रवाई लंबित हो और ट्रांसफ़र की काउंटरपार्टी नहीं मिली, तो वही ब्लॉक reason और next_actions भी रखता है (देखें काउंटरपार्टी खोज)।

ये ही दो फ़ील्ड transaction.created और transaction.status.updated webhook payloads पर भी आते हैं (action_required)। देखें webhooks।

लागत विवरण

किसी बिल योग्य सुविधा के लेन-देन पर चलने तक null। अन्यथा { "total_price", "items": [ { "usage_type", "price", "details" } ] }, जिसमें हर मीटर्ड सुविधा (स्क्रीनिंग, एनरिचमेंट और इसी तरह) के लिए एक आइटम होता है।

मुद्रा रूपांतरण

preferred_currency_amount आपके एप्लिकेशन की पसंदीदा मुद्रा में परिवर्तित amount होती है, जो मिड-मार्केट दरों पर गणना की जाती है। लेकिन यदि आपने amount_in_default_currency दिया है, तो वही पहले से परिवर्तित मान बिना किसी बदलाव के उपयोग किया जाता है। amount पर लागू नियम शर्तें मूल राशि की तुलना करती हैं। जब आपको सभी मुद्राओं में एक ही थ्रेशोल्ड चाहिए, तब शर्तों में preferred_currency_amount का उपयोग करें।

अगले चरण

लेन-देन सबमिट करें

पूरा अनुरोध स्कीमा।

स्थितियाँ

हर स्थिति का क्या अर्थ है।

जोखिम स्कोरिंग

स्कोर की गणना कैसे होती है।

शुरुआत करें

सुविधाएँ

संदर्भ

कंसोल

लेन-देन रिस्पॉन्स स्कीमा: KYT payload संदर्भ

शीर्ष-स्तरीय संरचना

मुख्य फ़ील्ड

वित्तीय फ़ील्ड

स्थिति फ़ील्ड

पक्ष

`device`

भुगतान विधियाँ

नियम रन

अलर्ट

गतिविधियाँ

दस्तावेज़

प्रदाता परिणाम

Travel Rule

नेटवर्क स्नैपशॉट

टैग, metadata, props

सुधारात्मक कार्रवाई

लागत विवरण

मुद्रा रूपांतरण

अगले चरण

लेन-देन सबमिट करें

स्थितियाँ

जोखिम स्कोरिंग

​शीर्ष-स्तरीय संरचना

​मुख्य फ़ील्ड

​वित्तीय फ़ील्ड

​स्थिति फ़ील्ड

​पक्ष

​device

​भुगतान विधियाँ

​नियम रन

​अलर्ट

​गतिविधियाँ

​दस्तावेज़

​प्रदाता परिणाम

​Travel Rule

​नेटवर्क स्नैपशॉट

​टैग, metadata, props

​सुधारात्मक कार्रवाई

​लागत विवरण

​मुद्रा रूपांतरण

​अगले चरण

लेन-देन सबमिट करें

स्थितियाँ

जोखिम स्कोरिंग

शीर्ष-स्तरीय संरचना

मुख्य फ़ील्ड

वित्तीय फ़ील्ड

स्थिति फ़ील्ड

पक्ष

`device`

भुगतान विधियाँ

नियम रन

अलर्ट

गतिविधियाँ

दस्तावेज़

प्रदाता परिणाम

Travel Rule

नेटवर्क स्नैपशॉट

टैग, metadata, props

सुधारात्मक कार्रवाई

लागत विवरण

मुद्रा रूपांतरण

अगले चरण