정의
Velocity Check는 동일한 결제 수단(카드번호), IP 주소, 이메일, 디바이스 핑거프린트, 배송지 등 특정 식별자가 짧은 시간 안에 몇 번이나 거래를 시도했는지를 추적하여 부정거래(사기 결제, 카드 도용)를 탐지하는 결제 리스크 관리 기법입니다.
DTC 브랜드에서 카드 도용범은 훔친 카드 정보를 확보한 뒤, 최대한 빨리 여러 건의 주문을 연속으로 넣고 상품을 빼돌리려 합니다. Velocity Check는 이 속도(velocity) 자체를 이상 신호로 간주합니다. 단일 거래만 보면 정상처럼 보여도, 10분 안에 같은 카드로 5건이 결제되면 그것은 사람의 정상 쇼핑 패턴이 아니기 때문입니다.
핵심은 "얼마나 많은 금액인가"가 아니라 "얼마나 짧은 시간에 얼마나 자주인가" 입니다.
비유로 이해하기
은행 창구를 떠올려 보세요. 한 고객이 하루에 한 번 100만 원을 인출하는 건 전혀 문제가 아닙니다. 그런데 같은 고객이 30분 사이에 8번, 그것도 서로 다른 ATM에서 인출한다면? 창구 직원은 즉시 이상하다고 느낍니다. 돈의 액수가 문제가 아니라 반복 속도가 문제인 것입니다.
Velocity Check는 이 직관을 알고리즘으로 구현한 것입니다. Shopify, Stripe Radar, Riskified, Forter 같은 솔루션은 모두 이 로직을 기본 탑재하고 있습니다.
공식
Velocity Check는 보통 슬라이딩 윈도우(Sliding Window) 방식으로 계산합니다.
Velocity Score = Σ (거래 건수 in Window T) × 가중치(식별자 유형) 조건: Velocity Score ≥ 임계값(Threshold) → 추가 인증 또는 결제 차단
실제 운영 예시:
동일 카드번호 기준: - 1시간 내 3건 초과 → 경고 플래그 - 24시간 내 5건 초과 → 3DS 재인증 요구 - 24시간 내 8건 초과 → 자동 결제 거절 동일 IP 기준: - 1시간 내 10건 초과 → 디바이스 핑거프린트 재확인
가중치는 보통 카드번호 > 이메일 > IP 순으로 높게 설정합니다. IP는 VPN이나 공용 와이파이로 쉽게 공유될 수 있기 때문입니다.
비교표: Velocity Check vs 다른 사기 탐지 기법
| 구분 | Velocity Check | AVS (주소 검증) | CVV 검증 | 3DS (3D Secure) |
|---|---|---|---|---|
| 탐지 대상 | 거래 **빈도/속도** | 청구지-배송지 불일치 | 카드 소유 여부 | 카드 소유자 인증 |
| 데이터 기준 | 시간 + 식별자 | 주소 데이터 | 카드 뒷면 3자리 | 은행 인증 |
| 실시간성 | 매우 높음 | 높음 | 높음 | 중간 (리다이렉트) |
| 오탐 위험 | 중간~높음 | 낮음 | 낮음 | 매우 낮음 |
| 주요 활용 | 대량 도용 카드 차단 | 배송 사기 | 기본 검증 | 책임 전가(Chargeback Shift) |
| DTC 체감 마찰 | 낮음 (백엔드) | 낮음 | 낮음 | 높음 (이탈률 ↑) |
Velocity Check는 단독으로 쓰기보다 AVS + CVV + 3DS와 조합할 때 가장 강력합니다.
실제 적용 시나리오 (DTC 관점)
시나리오 1: 한정판 드롭(Drop) 공격
한 스니커즈 브랜드가 금요일 오전 10시에 한정판을 출시했습니다. 봇(Bot)이 200개의 서로 다른 계정으로 동시에 결제를 시도합니다. 이때 동일 IP에서 1분 내 40건의 결제 시도가 감지되면 Velocity Check가 즉시 작동하여 해당 IP 대역을 차단합니다. 실제로 Shopify는 이런 드롭 공격에서 결제 시도의 약 15~20% 가 봇에 의한 것으로 추정합니다.
시나리오 2: 카드 테스팅(Card Testing)
사기범은 훔친 카드 번호 목록을 가지고 $1~$2짜리 저가 상품으로 유효성 테스트를 합니다. 이때 동일 디바이스에서 5분 내 12건의 소액 결제가 발생하면, 금액이 작아도 Velocity Check는 이를 명확한 이상 신호로 포착합니다.
시나리오 3: 정상 고객 오탐
블랙프라이데이에 한 충성 고객이 선물용으로 30분 내 6건을 결제했습니다. Velocity 임계값이 너무 낮게 설정되어 있으면 이 고객이 차단됩니다. 그래서 DTC 브랜드는 시즌별로 임계값을 동적으로 조정해야 합니다. 예를 들어 BFCM 기간에는 24시간 기준 건수를 평시 대비 1.5~2배로 완화하는 것이 일반적입니다.
흔한 오해
오해 1: "건수만 세면 된다."
아닙니다. 시간 창(Time Window) 과 식별자 조합이 핵심입니다. 1시간 기준 5건과 24시간 기준 5건은 완전히 다른 의미입니다. 또한 카드+이메일+IP를 교차 조합해야 정확도가 올라갑니다.
오해 2: "차단이 많을수록 좋다."
오탐(False Positive)은 곧 매출 손실입니다. 업계 벤치마크로 Velocity 기반 룰의 오탐률은 5~15% 수준이며, 이를 3% 이하로 낮추는 것이 우수한 리스크 엔진의 기준입니다.
오해 3: "한 번 걸리면 영구 차단."
대부분의 솔루션은 스코어 기반입니다. 걸린 거래는 재인증(3DS)을 요구하고, 통과하면 정상 처리됩니다. 영구 블랙리스트는 확정된 사기 이력에만 적용합니다.
오해 4: "Velocity Check는 카드 사기만 잡는다."
반품 사기(Return Abuse), 프로모션 코드 남용, 리셀러 봇, 계정 탈취(ATO)까지 폭넓게 커버합니다.
관련 용어
- Card Testing (카드 테스팅): 훔친 카드의 유효성을 소액 결제로 확인하는 수법. Velocity Check의 주요 탐지 대상.
- Device Fingerprinting (디바이스 핑거프린트): 브라우저·하드웨어 특성으로 기기를 식별. Velocity의 핵심 식별자.
- 3D Secure (3DS): 카드사 인증 단계. Velocity 플래그 발생 시 재인증 수단으로 활용.
- Chargeback (차지백): 고객이 카드사에 결제 취소를 요청하는 절차. Velocity Check는 차지백 사전 예방 도구.
- Risk Scoring (리스크 스코어링): 여러 신호를 종합해 거래 위험도를 수치화. Velocity는 그중 하나의 피처(Feature).
- Rate Limiting (레이트 리미팅): API/서버 레벨에서 요청 빈도를 제한. Velocity Check와 개념적으로 유사하나 목적이 다름(보안 vs 리소스 보호).
요약: Velocity Check는 "속도가 곧 이상 신호"라는 원리로 작동하는 결제 사기 방어의 1차 방어선입니다. DTC 브랜드는 이를 단독 룰이 아닌 다층 리스크 스택의 한 레이어로 배치하고, 시즌·카테고리별로 임계값을 지속 튜닝해야 매출과 보안을 동시에 지킬 수 있습니다.