사용 시기
지갑 스크리닝은 거래 테이블에 아무것도 기록하지 않습니다. 규칙, 알림, webhook과 함께 모니터링되는 거래에 스크리닝 결과를 연결해야 한다면 대신 거래를 제출하십시오.
사전 요구 사항
애플리케이션에 거래 모니터링이 구성되어 있어야 하며, 관리형 제공업체 또는 기존 제공업체 키 중 하나를 사용해야 합니다. Business Console에서 거래 > 설정 > Provider Preferences 순서로 구성하십시오. 제공업체가 구성되어 있지 않으면 endpoint는409 Conflict를 반환합니다.
요청
POST https://verification.didit.me/v3/wallet-screening/
인증은 x-api-key 헤더로 합니다.
체인 지원 범위
관리형 스크리닝은 지갑과 거래 해시 스크리닝 모두에 대해 Base(BASE), Optimism(OP), Arbitrum One(ARB)을 지원합니다.
연결된 제공업체마다 지원 범위가 다를 수 있습니다. 체인은 선택한 제공업체와 계정에서도 지원되어야 합니다.
Celo(CELO), Mode(MODE), Plume(PLUME)은 연결된 TRM Labs 계정(Marketplace, 자체 키 사용)을 통해 스크리닝합니다. 관리형 스크리닝은 이들을 지원하지 않으며 400을 반환합니다.
같은 주소라도 체인마다 활동 내역과 위험도가 다를 수 있으므로, 다른 EVM 네트워크에 ETH를 제출하지 마십시오.
관리형 스크리닝에서 USDT와 USDC는 이전 버전과의 호환을 위한 Ethereum 별칭입니다. 이 토큰이 존재하는 모든 네트워크를 검색하지는 않습니다.
지갑이 실제로 사용하는 체인에 맞는 네트워크 식별자를 사용하십시오(ETH, TRX, SOL, MATIC, BNB, BASE, OP, ARB, AVAX, ADA, XLM, HBAR, 또는 TRM Labs 사용 시 CELO, MODE, PLUME).
기록된 거래의 토큰은 transaction_details.currency에 유지하고, 네트워크는 transaction_details.crypto_params.crypto_chain에 따로 지정하십시오.
자세한 내용은 자산 및 네트워크 선택을 참조하십시오.
Response
응답은 표준화된 스크리닝 결과이며, 거래 스크리닝에서 반환되는WALLET_SCREENING 제공자 결과와 형태가 동일합니다.
severity가 설정되는 방식. severity는 정규화된 risk_score가 속한 구간입니다. 0-9 → UNKNOWN, 10-39 → LOW, 40-69 → MEDIUM, 70-89 → HIGH, 90-100 → CRITICAL입니다. UNKNOWN은 가장 낮은 구간이지, “데이터 없음” 상태를 뜻하지 않습니다. risk_score: 0(일반적인 깨끗한 주소의 경우)은 제공자가 부정적인 평가를 반환하지 않았다는 뜻이고, 1-9 범위의 0이 아닌 점수는 실제 신호지만 LOW 미만의 수준입니다. 따라서 구간만 보지 말고 risk_score 자체를 확인하십시오. 어느 경우든 UNKNOWN을 “안전” 또는 “통과”로 표시하지 마십시오.direction은 위험 모델을 바꾸지 않습니다. 선택 사항인 direction 필드는 컨텍스트로만 제공자에게 전달됩니다. risk_score, severity 또는 반환되는 노출 내역 목록에는 영향을 주지 않습니다. source_of_funds와 destination_of_funds는 항상 모두 반환됩니다. 따라서 direction을 변경하거나 생략해도 이미 스크리닝된 주소를 다시 스크리닝할 필요는 없습니다.위험 요인
risk_factors는 “이 주소의 점수가 왜 이렇게 매겨졌는가”에 대한 순위별 답변입니다. 제공자는 자체 모델로 주소를 평가하며 판정만 반환합니다. 예를 들어 Merkle Science는 정수 0-5를 반환하므로, risk_score만으로는 조치를 취할 수 없습니다. 각 항목은 하나의 요인을 나타내며, 고위험 항목이 먼저 오고 그다음에는 해당 요인을 통해 이동한 금액 순으로 정렬됩니다.
고점수이지만
is_high_risk 요인이 없는 경우도 실제로 의미 있는 결과입니다. 제공자가 제재, PEP 또는 귀속된 기관 일치 여부를 보고하지 않은 채 자체 노출 모델로 주소를 평가했다는 뜻입니다. 목록에 있는 요인은 점수의 근거가 된 자금 흐름입니다. summary에 이 점이 명시되므로, 이런 주소는 확인된 일치 결과가 아니라 “흐름을 검토할 대상”으로 취급하십시오. risk_factors는 가장 강한 다섯 가지 요인으로 제한되며, source_of_funds와 destination_of_funds에는 전체 내역이 항상 포함됩니다.risk_factors는 최상위 필드이며 중첩된 필드가 아닙니다. 이 필드가 도입되기 전에 스크리닝된 결과에는 키 자체가 없습니다. 이 경우 설명이 비어 있다고 가정하지 말고 빈 목록으로 읽으십시오.노출 내역
source_of_funds / destination_of_funds의 각 항목은 주소가 자금을 주고받은 엔티티 하나를 나타냅니다.
거래 상대방 연결
counterparty_connections에는 제공자가 스크리닝된 주소에 귀속시킨 엔티티가 나열됩니다. Merkle Science의 경우 이 값은 주소 자체의 소유자 태그와 사용자 태그에서 가져오므로 같은 엔티티가 두 번 나타날 수 있습니다. 또한 자금 흐름 정보가 없으므로 received_usd, sent_usd, received_hops, sent_hops는 null이고 percentage는 0.0입니다. 자금 흐름은 source_of_funds와 destination_of_funds에서 확인하십시오.
예시
Merkle Science로 OFAC 제재 목록에 있는 주소를 스크리닝한 실제 응답입니다.raw_response만 줄였고 report_signature는 대체했습니다.
sanctions_hit: true는 지갑 자체가 제재 대상임을 나타낼 수도 있고 자금에 제재 노출이 있음을 나타낼 수도 있습니다. 따라서 이 값만으로 스크리닝된 지갑 소유자가 제재 대상이라는 뜻은 아닙니다.
같은 스크리닝이 기록된 거래에 대해 실행되면 규칙은 custom_values.wallet_sanctioned를 읽을 수 있으며, 이 값은 제공자가 지갑 자체를 제재 대상 엔티티에 귀속시킨 경우에만 true입니다. 또한 custom_values.aml_sanctions_exposure_pct도 읽을 수 있습니다.
규칙용 스크리닝 필드를 참조하십시오.
귀속과 노출을 구분하려면 risk_factors, source_of_funds, destination_of_funds를 함께 읽으십시오.
단계별 설명은 암호화폐 및 지갑 스크리닝을 참조하십시오.
PDF 보고서
스크리닝 결과의 Didit 브랜드 PDF를 받으려면report_signature를 포함한 응답 본문 전체를 그대로 POST /v3/wallet-screening/pdf/에 다시 전송하십시오. 이 요청은 상태를 저장하지 않습니다. 제공자 호출이 없고 추가 요금도 없으며 아무것도 저장되지 않습니다. 재전송 전에 서명된 필드(risk_score, severity, sanctions_hit 등)를 하나라도 수정하면 400으로 실패합니다.
Billing
AML 모니터링 사용량 1회는 성공한 스크리닝마다 과금되며, 요금은 거래 연동 암호화폐 스크리닝과 동일합니다. 관리형 및 연결된 키의 요금은 요금을 참조하세요. 샌드박스 애플리케이션은 과금되지 않습니다. 유효성 검사 오류(400)와 AML 제공자가 구성되지 않은 오류(409)는 절대 과금되지 않습니다.
오류
다음 단계
API 레퍼런스
Screen Wallet endpoint의 전체 요청 및 응답 스키마.
Screen Wallet PDF
스크리닝 결과를 Didit 브랜드가 적용된 PDF로 렌더링합니다.
암호화폐 및 지갑 스크리닝
거래 생성 중 자동 스크리닝과 결과 모델.