결정 규칙과 임계값
모든 검사는 경고를 발생시키며, 각 경고에 무엇을 할지는 여러분이 결정합니다 - 통과, 검토, 거절. 이 매핑이 바로 여러분의 위험 성향이 실제로 담기는 곳입니다.
각 단계는 자신의 경고를 통과, 검토, 거절 중 하나의 액션에 매핑합니다. 거절로 구성된 단계는 워크플로우를 중단시키므로 - 이후 단계는 절대 실행되지 않고, 그에 대한 과금도 없습니다. 그래서 규칙 순서는 위험 결정인 동시에 비용 결정이기도 합니다.
#결정이 실제로 이루어지는 곳
워크플로우를 "내가 실행하는 검사들"로만 생각하기 쉽습니다. 하지만 검사는 절반에 불과합니다. 나머지 절반 - 그리고 승인율을 결정하는 절반 - 은 각 검사의 경고가 무엇을 하도록 설정되어 있는가입니다.
- 각 기능 노드는 자체 임계값과 자체 결정을 가집니다.
- 검사를 필수로 할지 선택으로 할지도 누가 통과하는지에 대한 결정입니다.
- 변경된 규칙은 워크플로우가 저장되어야 새 세션에 반영됩니다.
모든 단계에 대해, 발생할 수 있는 각 경고는 세 가지 액션 중 하나에 매핑됩니다.
| 액션 | 효과 |
|---|---|
| Approve(또는 무시) | 경고는 기록되지만 결과를 바꾸지 않음 |
| Review | 세션이 In Review로 이동해 사람이 판단 |
| Decline | 세션이 거절되고 워크플로우가 중단됨 |
이 매핑이 곧 구성으로 표현된 여러분의 정책입니다.
#거절은 워크플로우를 중단시킵니다
이는 사람들을 가장 놀라게 하는 동작이므로 명확히 짚고 넘어갈 가치가 있습니다. 어떤 단계가 거절되면 실행은 그 자리에서 멈춥니다. 그 이후의 단계는 절대 실행되지 않습니다.
두 가지 결과가 따릅니다.
- 결과에는 예상했던 검사가 빠져 있을 것입니다. 실패한 것이 아니라 애초에 실행되지 않은 것입니다. 신분증 인증 단계에서 거절된 세션에는 라이브니스도, 얼굴 일치도, AML도 없습니다.
- 그에 대한 과금이 없습니다. 과금은 완료된 기능 단위이므로, 실행되지 않은 단계는 비용이 들지 않습니다.
#규칙 순서로 비용 제어하기
거절이 플로우를 중단시키므로, 단계 순서는 지출을 조절하는 지렛대입니다. 비용이 큰 묶음 앞에 저렴한 위험 검사를 배치하면, 어차피 통과하지 못했을 트래픽이 비싼 부분에 비용이 들기 전에 멈추게 됩니다.
$0.03짜리 기기 및 IP 분석을 전체 KYC 플로우 앞에 두는 것이 표준적인 예입니다. 어차피 거절할 트래픽을 저렴하게 걸러냅니다.
여기서 절충되는 것은 사용자 경험과 오탐(false positive)입니다. 기기 및 IP 신호는 Didit이 제공하는 검사 중 가장 노이즈가 많습니다 - 기업 네트워크, 통신사 NAT, 클라우드 브라우저는 모두 정상 사용자를 공유 주소 뒤에 놓습니다. 전체 플로우를 여기에 걸어 거절로 두면 실제 고객까지 차단하게 되므로, 자체 트래픽을 직접 측정하지 않았다면 거절이 아니라 검토로 라우팅하세요.
#자동화보다 판단이 필요한 규칙
일부 경고는 명확하며 거절해야 합니다. MRZ 체크섬 실패, 발급 기관까지 체인이 이어지지 않는 칩 서명, 블록리스트에 있는 얼굴 등입니다. 이런 것들은 무결성 실패입니다.
반면 다음은 거의 언제나 검토가 더 낫습니다.
- 주소 증빙에서의 부분 주소 일치 - 형식이 국가마다 다릅니다.
- 데이터베이스 검증에서의 부분 이름 일치 - 공식 출처마다 이름 기록 방식이 다릅니다.
- 신뢰도가 낮은 AML 후보 히트 - 흔한 이름은 계속해서 이를 발생시킵니다.
- 경계선상의 얼굴 일치 - 얼굴 일치 점수와 임계값을 참고하세요.
- 중복 얼굴 플래그 - 신규 계정이라면 사기이고, 재방문 고객이라면 정상입니다.
그리고 일부는 판정이 아니라 재시도가 어울리는 사용성 문제입니다. 읽히지 않은 NFC 칩, 흐릿한 캡처, 끊긴 카메라 프레임 등입니다.
#연령 정책
최소 연령과 최대 연령은 워크플로우별로 설정하며, 위반 시 어떤 액션을 취할지는 여러분이 선택합니다. MINIMUM_AGE_NOT_MET은 곧바로 거절할 수도 있고, 정책상 증빙과 함께 예외를 허용한다면 검토로 라우팅할 수도 있습니다. 둘 다 타당한 선택이니 신중하게 고르세요.
#추출된 데이터에 대한 커스텀 규칙
경고별 매핑 외에도, 단계가 추출한 데이터를 기준으로 규칙을 작성할 수 있습니다. 예를 들어 추출된 필드가 특정 값을 가질 때 거절하는 식입니다. 두 가지를 기억하세요.
- 규칙은 해당 단계가 실제로 생성한 데이터에 대해서만 작동할 수 있습니다. OCR이 그 필드를 추출하지 못했다면 규칙이 판단할 대상이 없습니다.
- 거절하는 규칙도 위와 동일하게 워크플로우를 중단시킵니다.
보호 대상 특성(protected characteristic)을 기준으로 작동하는 규칙을 만들고 있다면, 엔지니어링 문제이기 전에 컴플라이언스 팀과 함께 검토해야 할 법률적 문제로 다루세요.
#단계뿐 아니라 규칙도 테스트하세요
워크플로우의 단계는 눈으로 보고 쉽게 검증할 수 있습니다. 규칙은 그렇지 않습니다 - 경고가 생각한 대로 라우팅되는지 아는 유일한 방법은 실제로 그 경고를 발생시켜 보는 것입니다.
샌드박스는 바로 이를 위해 존재합니다. 각 시나리오는 특정 경고 하나를 강제하므로 각 규칙의 액션을 처음부터 끝까지 확인할 수 있습니다. decline_document_expired, review_face_match_borderline, decline_aml_hit, review_poa_partial_match 등이 있습니다. 샌드박스에서 테스트하기를 참고하세요.
거절 경로만큼이나 검토 경로도 꼼꼼히 테스트하세요. 검토로 라우팅되는 규칙은 실제로 누군가 그 큐를 처리할 때만 쓸모가 있으며, 여러분의 검토 프로세스가 실제로 작동하는지 알아보는 방법은 실제 고객이 기다리기 전에 합성 세션을 그 경로로 통과시켜 보는 것입니다.
#변경 사항은 새 세션에 적용됩니다
워크플로우를 수정해도 이미 생성된 세션에는 소급 적용되지 않습니다. 세션은 생성 당시의 구성을 그대로 유지하므로, 규칙을 변경한 뒤에는 기존 세션을 다시 확인하지 말고 새 세션으로 테스트하세요.