[Kaggle] IEEE-CIS Fraud Detection - 이상거래 탐지 문제 정의와 데이터 구조 (1)

IEEE-CIS 대회는 처음 보면 “거래 단위 이진 분류”처럼 보인다. 나도 처음엔 그랬다. 그런데 대회 서머리랑 1등 솔루션 글을 몇 개 읽다 보니, 이건 모델 고르는 문제라기보다 ‘데이터를 어떻게 바라보느냐’가 먼저 정해지는 대회라는 느낌이 확 왔다. 그래서 1일차는 모델/성능 얘기는 잠깐 내려두고, 이상거래 탐지로 어떻게 정의할지, 그리고 데이터 구조에서 무엇을 먼저 읽어야 하는지만 깔끔하게 정리해본다. (이거 안 잡고 들어가면 계속 헤매더라… ㅎ.ㅎ)

 

1. 문제 정의

1.1 타깃 라벨(isFraud)의 한계

IEEE-CIS에서 제공하는 isFraud는 해당 거래가 사기로 확인되었는지 여부를 나타내는 라벨이다.
겉으로 보면 명확한 정답처럼 보이지만, 대회 서머리와 상위 솔루션에서는 이 라벨을 그대로 신뢰하지 않았다는 점이 반복해서 언급된다.

 

그 이유는 크게 세 가지다 👇

 

첫째, 사기 여부는 사후적으로 판별된다.
실제 결제 시스템에서는 거래 시점에 바로 사기 여부가 확정되지 않는 경우가 많다. 일정 시간이 지난 뒤 사용자 신고, 추가 검증 등을 통해 사기로 판별되기 때문에, isFraud = 0이라고 해서 “정상 거래가 확실하다”고 말하기 어렵다.

둘째, 라벨링 기준이 일관되지 않다.
어떤 거래는 금액이나 패턴이 충분히 이상해 보여도 라벨이 0으로 남아 있고, 반대로 경계선에 있는 거래가 1로 표시된 경우도 존재한다. 상위 솔루션 write-up에서도 라벨 노이즈 가능성을 전제로 접근했다는 언급이 자주 나온다.

셋째, 극단적인 클래스 불균형이 해석을 왜곡한다.
이상 거래 비율이 매우 낮은 상황에서, 단순 분류 성능은 쉽게 과대평가될 수 있다. 특히 랜덤 검증을 사용할 경우, 모델이 실제로는 “이상 패턴을 이해하지 못했는데도” 높은 점수를 얻는 상황이 발생한다.

이런 이유로 상위권 솔루션에서는 isFraud를
-> 반드시 맞혀야 할 절대적 정답” 보다는 “모델이 만든 이상 점수가 어느 정도 타당한지를 확인하는 기준”으로 다루는 경우가 많다.

 

1.2 이상거래 탐지 정의

이러한 특성 때문에 이 문제를 단순한 이진 분류로 보기보다는 이상거래 탐지 문제로 재정의하는 접근이 상위권에서 많이 사용된다. 핵심은 거래를 바로 정상/비정상으로 나누는 것이 아니라, 정상 거래 패턴을 기준으로 각 거래가 얼마나 이질적인지를 연속적인 점수(anomaly score)로 표현하는 것이다.

 

 

2. 데이터 구조

2.1 Transaction 데이터 (거래 관련)

TransactionID : 거래를 식별하기 위한 고유 ID
isFraud : 해당 거래가 사기로 확인되었는지 여부 (train 데이터에만 존재)
TransactionDT : 기준 시점으로부터의 상대적 거래 시간
TransactionAmt : 거래 금액
ProductCD : 거래 상품 코드
card1~card6 : 카드 관련 정보
addr1, addr2 : 주소 관련 정보
dist1, dist2 : 거리 관련 정보
P_emaildomain : 구매자 이메일 도메인
R_emaildomain : 수신자 이메일 도메인
C1~C14 : 카운트 관련 익명 변수
D1~D15 : 날짜/시간 관련 익명 변수
M1~M9 : 매칭 여부 관련 익명 변수
V1~V339 : 익명화된 수치형 변수

 

2.2 Identity 데이터 (접근 환경 관련)

TransactionID : transaction 데이터와 조인을 위한 키
DeviceType : 사용된 디바이스 유형
DeviceInfo: 디바이스 정보
id_01~id_38 : 익명화된 사용자/환경 관련 변수

 

3. 상위 솔루션의 핵심 구조

대회 서머리와 상위 솔루션을 정리해보면 모델이나 세부 기법은 달라도 문제를 바라보는 구조는 상당히 유사하다. IEEE-CIS에서 성능이 잘 나온 접근들은 대부분 아래 흐름을 공유한다.

3.1 거래 단위 접근의 한계

상위 솔루션들은 개별 거래를 독립 샘플로 보지 않는다. 단일 거래 정보만으로는 정상과 이상을 안정적으로 구분하기 어렵고, 거래 간 관계를 고려하지 않으면 패턴이 쉽게 깨진다. 따라서 분석 단위를 거래 자체가 아니라 거래를 수행한 주체의 반복 행동으로 확장한다.

 

3.2 UID 기반 거래 재구성

이를 위해 카드, 주소, 일부 시간 관련 컬럼을 조합해 UID(유사 고객 ID)를 정의한다. UID는 고객 식별을 위한 값이 아니라

유사한 거래를 묶기 위한 기준이다. 이 단계에서 거래는 더 이상 개별 사건이 아니라 하나의 행동 시퀀스로 해석된다.

 

3.3 행동 패턴 중심의 피처 구성

UID 자체는 모델 입력으로 사용하지 않는다. 대신 UID 단위로 거래를 집계해 평균 거래 금액, 거래 간 시간 간격, 특정 값의 등장
빈도 등 행동 패턴 요약 피처를 만든다. 이는 모델이 특정 거래를 암기하는 것을 방지하고, 정상 거래 분포를 학습하도록 유도한다.

 

3.4 구조적 결측 활용

Identity 데이터의 결측은 단순 누락이 아니라 거래 환경 차이를 반영한 구조적 특성으로 취급된다. 여러 컬럼이 동시에 결측되는 패턴은 특정 거래 유형을 구분하는 기준이 되며, 상위 솔루션에서는 결측 여부 자체를 중요한 정보로 활용한다.

 

3.5 시간 기준 검증

Identity 데이터의 결측은 단순 누락이 아니라 거래 환경 차이를 반영한 구조적 특성으로 취급된다. 여러 컬럼이 동시에 결측되는 패턴은 특정 거래 유형을 구분하는 기준이 되며, 상위 솔루션에서는 결측 여부 자체를 중요한 정보로 활용한다.

 

아직 모델은 하나도 안 돌렸지만, 이 정도 기준이 정리되니까 확실히 마음이 덜 불안해졌다. 이제야 제대로 출발선에 선 느낌이다… 😌 ㅎㅎ