POST /v3/workflows/와 PATCH /v3/workflows/{settings_uuid}/의 features 배열 각 항목 안에서 다음 config 필드를 사용합니다.
features 배열로 선형 노드 기반 워크플로를 구성합니다. 기능은 실행 순서대로 정확히 보내야 합니다.
기능을 실행하는 엔진(Didit 자체 엔진 또는 제3자 제공업체)은 아래 config 필드에 포함되지 않습니다. 이는 콘솔의 Marketplace에서 관리하며, 해당 기능의
config 객체에 provider_key와 fallback_to_native를 자동으로 설정합니다.검증 규칙
config.documents_allowed가 생략되거나null또는{}이면OCR은 지원되는 모든 국가와 문서 유형을 기본값으로 사용합니다. 사용자 지정documents_allowed객체를 보내는 경우, 유효한 국가를 하나 이상, 활성화된 문서 유형을 하나 이상 포함해야 합니다. 각 문서 구성에서sides를1로 설정하면 앞면만,2로 설정하면 앞면과 뒷면을 촬영합니다.QUESTIONNAIRE에는config.questionnaire_uuid가 필요합니다.KYB_DOCUMENTS에는config.kyb_required_document_groups가 필요합니다.SIGNATURE는 적격 서명을 사용할 수 있게 될 때까지signature_level: "qes"를qes_not_available오류와 함께 거부합니다. 또한 워크플로에서signature_availability.aes가false인 동안에는 새 단계에서signature_level: "aes"를aes_not_available오류와 함께 거부합니다. 세션을 생성할 때 서명 문서가 있어야 합니다.signature_documents_source가workflow로 설정된 경우 해당 단계에는 콘솔에서 업로드한 문서가 필요하며, 문서가 없는 단계는 초안 상태로 둘 수 있지만 프로덕션 환경으로 전환할 수 없습니다.session으로 설정된 경우 모든 생성 호출에sign.documents를 포함해야 합니다.- 간단한 워크플로 요청에서
FACE_MATCH는OCR뒤에 와야 합니다. NFC와DATABASE_VALIDATION이 같은 워크플로에 포함되면OCR이 필요합니다.AML의 앞에는OCR,KYB_REGISTRY,DOCUMENT_AI중 하나가 와야 합니다. 앞에DOCUMENT_AI만 있는 경우 검사 대상full_name을 입력할 수 있어야 합니다. 즉,full_name키가 이미 설정된 상위 Document AI 필드에서 가져오거나(자동으로 매핑됨), 명시적인config.aml_field_sources항목에서 가져와야 합니다(AML 참고).KYB_DOCUMENTS,KYB_KEY_PEOPLE같은 KYB 하위 기능은 워크플로에서 앞서KYB_REGISTRY가 필요합니다.- 워크플로는 개인(KYC) 워크플로이거나 기업(KYB) 워크플로 중 하나여야 하며, 둘을 함께 사용할 수 없습니다. KYB 기능(
KYB_REGISTRY,KYB_DOCUMENTS,KYB_KEY_PEOPLE)을 하나라도 사용하는 워크플로는AML,DOCUMENT_AI,QUESTIONNAIRE,PHONE_VERIFICATION,EMAIL_VERIFICATION,IP_ANALYSIS,SIGNATURE와만 결합할 수 있습니다.OCR,LIVENESS,FACE_MATCH,NFC,PROOF_OF_ADDRESS,DATABASE_VALIDATION,AGE_ESTIMATION과 같이 개인 전용 기능은 포함할 수 없으며, 개인 워크플로에는 KYB 기능을 포함할 수 없습니다. 기업 워크플로에서DOCUMENT_AI는is_full_name으로 표시된 필드를 개인이 아닌 확인된 회사와 비교합니다. 회사의 주요 인물을 확인하려면 별도의 KYC 워크플로를 만들고,KYB_KEY_PEOPLE노드에서kyb_ubo_verification_workflow,kyb_officer_verification_workflow,kyb_shareholder_verification_workflow를 사용해 해당 워크플로를 참조하세요. - 작업 필드는 아래 필드에서 제한된다고 명시하지 않는 한
DECLINE,REVIEW,NO_ACTION을 사용합니다. - 점수 및 임계값 필드는 더 좁은 범위가 나열되지 않는 한
0에서100사이의 숫자입니다.
공통 상태 규칙
모든 기능은 선택 사항인status_rules 배열을 지원합니다. 필드 조건이 일치할 때 기능 상태를 재정의하려면 이 배열을 사용하세요.
위 예시는 다음과 같이 읽습니다.
kyc.extra_fields.profession이 최소 점수 80으로 Soft. Engineer와 퍼지 일치하면 → 기능 상태를 Declined로 설정합니다.
신분증 인증의 경우 추출된 extra_fields 값을 대상으로 지정할 수 있습니다. 예를 들면 kyc.extra_fields.profession, 운전면허 등급의 유효 기간 날짜인 kyc.extra_fields.dl_class_code_b_from과 kyc.extra_fields.dl_class_code_b_to, 또는 등급별 제한/정보 코드인 kyc.extra_fields.dl_class_code_b_notes(영국 면허증의 12번 열)가 있습니다. 이 값은 OCR 결과의 extra_fields 객체에서 가져오며, expected_details의 일부가 아닙니다.
dl_class_code_*_from과 dl_class_code_*_to는 항상 유효한 ISO 날짜이거나 extra_fields에 없습니다. Didit은 날짜 필드에 읽을 수 없는 OCR 텍스트를 반환하지 않습니다. 등급 표의 셀을 읽을 수 없으면 원시 문자열로 보내지 않고 해당 필드를 생략하므로, 읽을 수 없는 등급 날짜를 처리하려면 필드가 항상 존재한다고 가정하지 말고 is_empty 연산자를 사용하세요.value_type: "relative_date"와 { "direction": "past" | "future", "amount": number, "unit": "days" | "months" | "years" } 형태의 값 객체를 사용합니다. 예를 들어 operator: "less_than"과 { "direction": "past", "amount": 3, "unit": "years" }를 함께 사용하면 오늘부터 3년보다 오래된 날짜와 일치합니다.
특정 단계와 비교
그래프 워크플로는 같은 기능을 여러 번 실행할 수 있습니다. 예를 들어 신분증 인증 단계를 세 개 둘 수 있습니다.value_type: "field"를 사용할 때는 값 뒤에 @<node_id>를 붙여 특정 단계에서 값을 읽을 수 있습니다. 참조하는 노드는 모든 경로에서 규칙이 속한 단계보다 항상 먼저 실행되는 기능 단계이거나, 규칙이 속한 단계 자체여야 합니다. 접미사가 없는 값은 규칙이 속한 단계에서 읽습니다.
kyc.full_name이 ocr_1 단계가 읽은 성명과 최소 점수 80으로 퍼지 일치하면 → 기능 상태를 Declined로 설정합니다.
콘솔에서는 변수 선택기가 캔버스의 단계 번호와 함께 해당 단계를 나열하며, 접미사는 자동으로 저장됩니다.
OCR / 신분증 인증
기능 값:OCR.
문서 라이브니스는 위의 여섯 개
document_liveness_* 임계값으로 설정하며, 신호별 판정 필드로는 설정하지 않습니다. portrait_replacement_action, printed_copy_action, screen_capture_action은 계정 수준 설정이므로 워크플로 기능 설정에서는 허용되지 않습니다. API는 저장할 때 알 수 없는 설정 키를 제거하므로, 여기에 보내도 아무 효과가 없습니다. 각 신호에는 0부터 100까지의 척도에 따른 거부 임계값과 검토 임계값이 있으며, 점수가 높을수록 문서가 진짜일 가능성이 높습니다.국가별 방법
methods는 ISO 3166-1 alpha-3 국가 코드를 키로 사용합니다. 각 국가에는 최대 세 개의 방법 객체를 포함할 수 있으며, 생략한 항목은 기본값을 따릅니다.
wallet.on_failure는 fallback_to_document, decline, retry 중 하나입니다. retry(지갑 전용이며, 해당 국가에서 문서 촬영이 꺼져 있어야 합니다)는 지갑 단계에서 로그인을 완료하지 못한 사용자가 다시 시도할 수 있도록 합니다. 이 경우 세션은 거부되지 않으며, 사용자가 완료하거나 세션이 만료될 때까지 열려 있습니다. id_lookup 스위치는 fallback_to_document 또는 decline만 사용할 수 있습니다.
지갑이나 조회가 성공하지 못했을 때에만 문서를 제공하고 첫 화면에서는 문서를 숨기려면 document.fallback_only를 설정하십시오. 예시는 핀란드를 사용합니다. 핀란드 신뢰 네트워크가 먼저 표시되고, 문서 촬영이 대체 수단입니다. 대체 수단에서 제공할 문서가 있도록, 핀란드에서는 documents_allowed에서 문서 유형(예: 여권과 신분증)도 활성화해야 합니다.
available이므로 해당 설정은 그대로 저장됩니다. 이 예시에서 지갑 블록은 의도적으로 제외되었습니다. 지갑은 카탈로그에서 available로 표시된 국가에서만 저장할 수 있으며, 그 밖의 국가에서 wallet.enabled: true를 설정하면 거부되어 조회 설정을 포함한 전체 저장이 실패합니다. 지갑이 available로 표시된 국가라면 해당 국가에 지갑을 추가하십시오:
API가 저장 시 적용하는 검증은 다음과 같습니다.
- 알 수 없는 국가 코드, 국가 내의 알 수 없는 키, 방법 내의 알 수 없는 키는 거부됩니다. 아무것도 조용히 삭제되지 않습니다.
- 어떤 방법도 활성화되지 않은 국가는 거부됩니다. 그곳의 누구도 인증할 수 없기 때문입니다.
- 지갑이나 조회는 해당 국가에서 문서 촬영이 활성화된 경우에만 문서 촬영으로 대체될 수 있습니다.
document.enabled가false인 국가에서fallback_to_document를 설정하면 대체할 곳이 없으므로 런타임에 거부됩니다. document.fallback_only: true는document.enabled가true이고 해당 국가의 지갑 또는 신분증 조회 중 하나 이상이 문서 촬영으로 대체되도록 설정되지 않으면 HTTP 400으로 거부됩니다.
methods를 작성하기 전에 기능 카탈로그를 확인하십시오. 콘솔의 국가 탭에서 보거나 didit_workflow_get_id_verification_methods_catalog MCP 도구로 확인할 수 있습니다. 동작, 적용 범위, 과금은 신분증 인증 방법에서 확인하십시오.
NFC / 전자여권
기능 값:NFC.
라이브니스 감지
기능 값:LIVENESS.
얼굴 대조
기능 값:FACE_MATCH.
연령 추정
기능 값:AGE_ESTIMATION.
전화번호 인증
기능 값:PHONE_VERIFICATION.
전화번호 인증은 조직이 첫 충전을 완료할 때까지 비활성화되어 있습니다.
전화번호 인텔리전스 보강은 선택 부가 기능입니다.
phone_enrichment_enabled가 true이면, 완료된 전화번호 인증마다 전화번호 인텔리전스가 보강되며, 표준 전화번호 인증 비용 외에 요청 건당 $0.05가 청구됩니다. 점수 기반 작업은 보강 점수를 사용할 수 있게 된 후에만 적용됩니다. 신뢰 지수, 전화 유형, 번호 이동 관련 작업은 보강이 실행되는 즉시 적용됩니다.소셜 활동 흔적 확인은 별도의 두 번째 부가 기능입니다. phone_social_enabled가 true이면, 완료된 전화번호 인증마다 번호가 등록된 온라인 플랫폼(메시징, 소셜 미디어, 전자상거래, 전문 서비스)도 함께 보고되며, 요청 건당 $0.05가 청구됩니다. phone_enrichment_enabled와 함께 또는 단독으로 활성화할 수 있으며, 두 부가 기능은 독립적으로 가격이 책정되고 청구됩니다. 확인 대상 플랫폼 어디에도 번호가 등록되어 있지 않다는 결과도 유효하고 청구되는 응답이며, phone_no_social_presence_action을 발동시킵니다. 워크플로 그래프에서 결과에 따라 분기하려면 phone.social_profiles_registered(번호가 등록된 플랫폼 수)를 사용하십시오.이메일 인증
기능 값:EMAIL_VERIFICATION.
이메일 인텔리전스 보강은 선택 추가 기능입니다.
email_enrichment_enabled가 true이면 완료된 각 이메일 인증에 이메일 인텔리전스가 보강되며, 표준 이메일 인증 비용에 더해 요청당 $0.05가 청구됩니다. 점수 기반 작업은 보강 점수를 사용할 수 있게 된 후에 적용되며, 유출 관련 작업은 보강이 실행되는 즉시 적용됩니다.소셜 흔적 확인은 별도의 두 번째 선택 추가 기능입니다. email_social_enabled가 true이면 완료된 각 이메일 인증에서도 해당 주소가 등록된 온라인 플랫폼(이메일 제공업체, 소셜 미디어, 전문 네트워킹, 전자상거래 및 엔터테인먼트 서비스)을 보고하며, 요청당 $0.05가 청구됩니다. email_enrichment_enabled와 함께 또는 단독으로 활성화할 수 있으며, 두 추가 기능은 가격과 청구가 독립적으로 적용됩니다. 확인 대상 플랫폼 중 어디에도 주소가 등록되어 있지 않다는 조회 결과도 유효하고 과금되는 응답이며, email_no_social_presence_action을 트리거합니다. 워크플로 그래프에서 결과에 따라 분기하려면 email.social_profiles_registered(주소가 등록된 플랫폼 수)를 사용하십시오.Database Validation
기능 값:DATABASE_VALIDATION.
예시:
400 오류로 거부되며, 오류 메시지에 해당 ID와 거부 이유가 포함됩니다. 이 경우 아무것도 저장되지 않습니다. 거부 대상은 카탈로그에 없는 ID, 다른 국가에 속한 ID, 아직 제공되지 않는 서비스, 그리고 단독 POST /v3/database-validation/ 엔드포인트를 통해서만 제공되는 서비스입니다. 입력값을 이전 단계에서 제공하지 않는 서비스도 같은 방식으로 거부되며, 누락된 입력값 목록이 함께 표시됩니다. 저장된 워크플로에 이미 포함되어 있지만 더 이상 실행할 수 없는 서비스는 다시 저장할 때 제거됩니다.
예를 들어 다음 아르헨티나 워크플로는 신분증 인증에서 DNI 번호와 성별을 읽고, 셀피 없이 RENAPER의 데이터와 두 값을 대조합니다.
LIVENESS 단계 뒤에 arg_renaper를 사용하세요. 얼굴 대조 점수와 임계값은 RENAPER를 참고하세요.
은행 인증
기능 값:BANK_VERIFICATION.
사용자가 은행 계좌를 인증하면, 은행이 확인해 주는 계좌 명의인은 워크플로의 앞선 단계에서 확정된 신원과 비교됩니다. 사용자는 두 가지 방법 중 하나로 인증합니다. 은행 로그인(open_banking)은 사용자가 자신의 은행에 로그인하는 방식이고, 계좌 조회(account_lookup)는 사용자가 계좌 정보를 입력하면 은행이 해당 계좌의 명의를 확인해 주는 방식입니다. bank_method_order와 각 국가의 methods는 국가별로 어떤 방식을 제공할지, 그리고 어떤 방식을 먼저 보여 줄지 결정합니다. 자세한 내용은 은행 인증 방식을 참조하십시오. 이 단계는 명의자 이름 일치 점수, 그 점수를 산출한 비교 내용, 사유 코드 같은 증거를 생성하며, bank_*_action 키들이 이 증거를 상태로 변환합니다.
노드가 아무 작업도 수행할지는 두 가지로 결정됩니다. bank_countries는 허용 목록이므로 빈 맵이면 은행을 제공하지 않고 확인도 실행하지 않습니다. 또한 사용자의 명의와 비교할 대상이 있어야 합니다. 이 노드 앞에 OCR, DATABASE_VALIDATION 또는 QUESTIONNAIRE 단계를 두거나, 세션 생성 시 expected_details를 보내거나, bank_field_sources로 필드를 직접 매핑하십시오. 이 중 어느 것도 없으면 소유 여부는 unknown으로만 나올 수 있으며, 이 경우의 처리는 bank_reference_identity_missing_action이 결정합니다.
은행 인증은 아직 출시 단계이므로
BANK_VERIFICATION 노드는 해당 기능이 활성화된 계정에서만 허용됩니다. 그 밖의 계정에서는 저장이 거부되며, 거부되었다는 사실이 메시지로 표시됩니다. 이 단계를 실행하는 경로 역시 여기서 설정하지 않습니다. 이는 콘솔의 Marketplace에서 설정되는 provider_key와 fallback_to_native 쌍이 자동으로 정합니다.계좌 연결
사용자가 인증할 수 없는 경우
사용자는 언제든 은행 없이 계속할 수 있으며, 이 단계가 사용자를 막다른 길에 두는 일은 없습니다. 자세한 내용은 사용자가 은행을 인증할 수 없는 경우를 참조하십시오.
사용자가 계속 진행한 이유에 따라, 세션에서 계속 진행을 의미하는 값은
bank_unsupported_action, bank_attempts_exhausted_action 또는 bank_skipped_action입니다. 단, 그보다 먼저 평가된 시도가 이미 단계를 결정한 경우에는 그 결정이 우선합니다. 자세한 내용은 판정 작업을 참조하십시오.
명의자 비교
계좌 확인
이 키들은 계좌 확인에만 적용됩니다. 은행 로그인은 자체 근접 일치 처리와bank_max_attempts를 그대로 유지합니다.
재무 데이터
bank_expected_currencies는 기본값인 ownership 동의만으로 동작합니다. 나머지 세 키는 실제 재무 데이터를 읽으므로 각각 bank_scopes에 해당 동의 범위가 있어야 하며, 없으면 저장이 거부됩니다.
저장되는 항목
판정 작업
설정 항목은 제한됨으로 표시되지 않는 한 모두DECLINE, REVIEW, NO_ACTION 중 하나를 받으며, 생략하거나 null을 보내면 아래의 기본값이 적용됩니다. 적극적인 소유권 증거가 아닌 것은 기본적으로 승인되지 않으며, 사용자에게 불리한 명확한 증거가 있을 때에만 거부됩니다.
추가 설정
이 설정 항목들은 선택 사항입니다. 각 작업 항목은DECLINE, REVIEW, NO_ACTION 중 하나를 받습니다.
예시
config 객체입니다. 은행 인증이 켜져 있고 선택한 경로가 나열한 국가를 지원하는 계정의 예입니다.
AML
기능 값:AML.
KYC 개인 스크리닝에는 다음 필드를 사용합니다:
KYB 기업 스크리닝에는 다음 필드를 사용합니다:
Document AI 단계로 추출한 주체 스크리닝
AML 단계는 보통OCR 단계(개인)나 KYB_REGISTRY 단계(회사)에서 스크리닝 대상을 읽습니다. 세금 증명서나 설립 증서처럼 표준화되지 않은 문서를 다루며 DOCUMENT_AI만 추출 단계로 쓰는 워크플로에는 이 두 단계가 없으므로, 각 스크리닝 입력값이 어디에서 와야 하는지 명시해야 합니다.
예시 - 워크플로 어디에도 신분증 문서가 없는 상태에서 멕시코 acta constitutiva에 명시된 회사를 스크리닝하는 경우:
기기 및 IP 분석
기능 값:IP_ANALYSIS.
예시:
duplicated_device_action과 별도로 recovered_device_action을 사용하십시오. 복구 기기 일치는 사기 조직 탐지를 위해 설계되었지만 여전히 자체 트래픽을 기준으로 보정해야 하므로, 롤아웃 중에 이 방식이 유용합니다.
위치 확인
기능 값:GEOLOCATION.
인증하는 동안 사용자가 어디에 있는지 확인합니다. 기기 위치 또는 연결의 IP 위치를 기준으로, 허용 구역과 차단 구역, IP 위치, 문서 주소와 대조합니다.
단계의 동작 방식은 위치 확인 문서를, 판단 필드는 보고서를 참고하십시오.
문서 주소까지의 거리를 확인하려면 신분증 인증 또는 주소 증명 뒤에 배치하십시오. 거리는 주소가 등록되어 있을 때만 측정되기 때문입니다.
geolocation_position_source를 설정하지 않으면, IP 위치까지의 거리를 구하기 위해 같은 워크플로에 기기 및 IP 분석 단계가 있어야 합니다.
모든 키는 선택 사항입니다. config가 비어 있는 단계는 기기에 250m 이내 정확도의 위치를 요청하고, 120초보다 오래되지 않은 위치를 받으며, 사용자에게 3회의 시도 기회를 주고, 구역 규칙은 적용하지 않습니다.
각 탐지 결과에는 고유한 작업 키가 있습니다. 설정하지 않은 작업 키는 선택한 geolocation_preset의 기본값을 따르며, 프리셋을 선택하지 않았다면 아래에 나온 키별 기본값을 따릅니다.
불확실하거나 거부된 위치의 기본 작업은 DECLINE이 아닌 REVIEW입니다. 권한이 거부되었거나 반경이 넓다는 사실만으로는 사기의 증거가 되지 않기 때문입니다.
직접 설정한 작업은 항상 프리셋보다 우선합니다.
재생된 챌린지(LOCATION_REPLAY_DETECTED)와 기기 증명 실패(LOCATION_INTEGRITY_FAILED)는 항상 거부되며, 작업 키가 없습니다.
영역 형태
geolocation_areas의 각 항목에는 id가 있습니다. 이 값은 A-Z a-z 0-9 _ - 문자로 이루어진 1~64자이며 목록 안에서 고유해야 합니다. 선택 사항인 label(최대 80자), type(allowed 또는 blocked), 그리고 형태를 정하는 kind도 있습니다.
목록에는 최대 50개의 영역을 담을 수 있으며,
is_geolocation_geofencing_enabled가 true인 동안에는 allowed 영역이 최소 하나 있어야 합니다.
geolocation_areas와 geolocation_geofencing_by_country는 함께 보낼 수 없습니다. geolocation_refusal_path: "end_session"을 사용하려면 geolocation_permission_denied_action이 REVIEW 또는 DECLINE이어야 합니다.
API는 결코 일치할 수 없는 영역(예: 공개된 경계가 없는 국가의 하위 행정구역)을 저장하지 않고 거부합니다.
예시:
주소 증명
기능 값:PROOF_OF_ADDRESS.
설문지
기능 값:QUESTIONNAIRE.
KYB 법인 등기부
기능 값:KYB_REGISTRY.
kyb_registry_fields_config는 설정 가능한 각 필드 키를 {"enabled": bool, "required": bool}에 매핑합니다. enabled: false이면 필드가 숨겨지고, enabled: true, required: false이면 선택 사항으로 표시되며, enabled: true, required: true이면 제출 시 필수가 됩니다. company_name, country_code, region은 항상 표시되고 필수이며 설정할 수 없습니다. 객체를 생략하거나 null 또는 {}로 설정하면 기본값이 적용됩니다. 기본값에서는 incorporation_date만 필수이고 다른 모든 필드는 선택 사항입니다.
registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme. 최종 사용자 동작은 설정 가능한 등기부 양식 필드를 참조하고, vat_number와 tax_number의 검사 방식은 VAT 및 납세자 번호 검증을 참조합니다.
KYB 문서
기능 값:KYB_DOCUMENTS.
KYB 주요 인물
기능 값:KYB_KEY_PEOPLE.
Document AI
기능 값:DOCUMENT_AI.
사용자에게 하나 이상의 문서를 요청하고, 비전 모델을 사용해 정의한 필드를 추출합니다. 구성된 각 필드는 분기에 사용할 수 있는 값 document_ai.<key>가 되며, 단계의 결과는 document_ai.status입니다.
document_ai_documents의 각 항목은 다음과 같은 문서입니다.
문서의
fields에 있는 각 항목은 다음과 같은 필드입니다.
예시:
전자 서명
기능 값:SIGNATURE.
인증된 사람 또는 회사의 주요 인물이 문서에 서명하도록 합니다. 수준은 Simple(기본값) 또는 고급(AES)입니다. 서명자를 검증하는 단계 뒤에 배치하세요: 신분증 인증, 그리고 코드 확인을 위한 이메일 인증 또는 전화번호 인증. 자세한 내용은 전자 서명을 참조하세요.
워크플로 문서의 필드는 콘솔의 템플릿 편집기에 배치됩니다. 세션 문서의 경우
sign.documents[].fields로 보내고, api.<key> 필드의 값은 sign.field_values로 보냅니다. 세션 생성을 참조하세요.
예시, 각 세션과 함께 보내는 문서의 경우: