의심스러운 거래를 찾아내는 감시자, 거래 모니터링 시스템(TMS) 테스트

1. 룰(Rule) 기반 시나리오 테스트:
- QA는 TMS에 설정된 룰 하나하나를 테스트 케이스로 만들어야 합니다.
- 예시 룰: “고객이 24시간 내에, 3개국 이상의 국가에서 카드를 사용하면 탐지한다.”
- 테스트 방법: 특정 테스트 계정으로, 서울, 뉴욕, 런던에서 각각 8시간 간격으로 카드 결제를 하는 테스트 데이터를 생성하고 시나리오를 수행합니다. 그리고 TMS가 해당 계정에 대해 경고를 정상적으로 발생시키는지 확인합니다.
2. 데이터 처리 및 집계(Aggregation) 테스트:
- TMS는 “일주일간 누적 송금액 5천만 원 이상”과 같이, 특정 기간의 데이터를 합산하여 판단하는 경우가 많습니다.
- QA는 테스트 데이터의 거래 일시를 정교하게 조절해가며, 시스템이 데이터를 정확하게 집계하고 룰을 적용하는지 검증해야 합니다.
3. 의심스러운 거래 보고(STR) 데이터 검증:
- 룰에 의해 탐지된 거래가 STR로 생성될 때, 보고서에 포함되는 데이터(고객 정보, 계좌 정보, 거래 정보, 탐지된 룰 등)가 빠짐없이 정확하게 기록되는지 데이터베이스 레벨에서 직접 확인합니다.

현직자만 아는 TMS 테스트 꿀팁

꿀팁 1: 테스트 데이터 설계가 전부다

‘TMS 테스트’의 성패는 ‘테스트 데이터’에 달려있습니다. 정상적인 고객, 의심스러운 고객, 고위험군 고객 등 다양한 프로필의 가상 고객 데이터를 미리 만들어 두어야 합니다. 그리고 이 고객들이 만들어내는 수만 건의 정상 거래 데이터와, 그 속에 정교하게 숨겨진 몇 건의 의심 거래 데이터를 설계하여 테스트해야 합니다.

꿀팁 2: 경계값과 예외 케이스를 노려라

룰의 ‘경계값’을 집중적으로 테스트하는 것이 효과적입니다. 예를 들어, ‘1천만 원 이상’이 탐지 기준이라면, 9,999,999원 거래(탐지되면 안 됨)와 10,000,000원 거래(탐지되어야 함)를 모두 테스트하여 룰이 명확하게 동작하는지 확인해야 합니다.

꿀팁 3: 룰 변경 시 회귀 테스트는 필수

새로운 룰이 추가되거나 기존 룰의 기준값이 변경될 때, 이 변경이 다른 룰의 동작에 영향을 주지는 않는지 반드시 ‘회귀 테스트’를 수행해야 합니다. 때로는 룰들이 서로 충돌하여 예상치 못한 결과를 낳을 수 있기 때문입니다.

결론: 데이터 속에서 진실을 찾는 일

‘거래 모니터링 시스템’ 테스트는 거대한 데이터의 바다에서 바늘 하나를 찾아내는 것과 같은, 섬세하고 정교한 품질 활동입니다.

QA는 범죄자의 입장에서 룰을 우회하는 시나리오를 상상하고, 데이터 과학자의 입장에서 룰의 논리적 허점을 찾아내야 합니다.

성공적인 ‘TMS’ 테스트는 우리 금융 시스템을 보이지 않는 위협으로부터 지키는 튼튼한 그물망을 만드는, 매우 가치 있는 일입니다.

부록: TMS 테스트 미니 체크리스트 ✅

고액 거래 탐지 룰이 기준 금액을 정확히 인지하는가?
단기간 반복 거래 탐지 룰이 횟수와 기간을 정확히 계산하는가?
특정 국가 또는 고위험 고객군에 대한 위험 가중치가 올바르게 적용되는가?
STR 보고 데이터는 원본 거래 데이터와 100% 일치하는가?
새로운 룰 추가 시, 기존 룰의 성능(처리 속도)에 영향을 주지 않는가?

참고 자료 (References)

Oracle – Oracle Financial Services Transaction Monitoring: https://www.oracle.com/financial-services/

이 글에서 다루는 것

‘거래 모니터링 시스템(TMS)’, 정확히 무엇인가요?

QA는 ‘거래 모니터링 시스템’의 무엇을 테스트해야 할까요?