P2P 내부자 사기: 직원과 결제가 장부와 어긋날 때

가상의 P2P 팀에서 세 가지 사실이 발견되었습니다. 은행 송금 한 건이 성공한 신청 두 건에 연결되어 있습니다. 지급 수취인이 승인 이후에 바뀌었습니다. 같은 거래 상대방의 예외 건 여러 개를 매번 같은 직원 두 명이 종결합니다. 내부자 사기를 의심할 만한 상황이지만, 어느 사실도 단독으로는 부정행위를 증명하지 않습니다. 다만 셋이 겹치면 돈과 기록이 아직 남아 있을 때 해당 작업을 멈추고 증거를 확인해야 합니다.

이는 여러 사례를 합친 방어 시나리오이며 특정 프로세서에 관한 이야기가 아닙니다. 여기서 말하는 내부 부정은 직원이 공모를 포함해 자신의 접근 권한이나 직무 권한을 고의로 남용하는 것을 뜻합니다. 실수, 불편한 인터페이스, 과부하 걸린 교대 근무도 비슷한 신호를 만들 수 있습니다. 그래서 통제는 모순을 찾아내고, 조사는 원인을 규명해야 하며, 원인 대신 혐의를 씌워서는 안 됩니다.

첫 번째 사례: 승인은 그럴듯하지만 돈은 부족하다

위조 영수증은 경험이 부족한 트레이더에게만 위험한 것이 아닙니다. 검토자가 실무자가 올린 문서만 본다면, 팀 내부에서 위조 영수증은 수동 처리의 편리한 근거가 됩니다. 그러면 두 사람이 형식상 승인에 참여하지만 둘 다 같은 신뢰할 수 없는 출처를 믿게 됩니다. 2인 승인 규칙만으로 독립성이 생기지는 않습니다.

입금을 확인하려면 거래 상대방의 스크린샷과 무관한, 실제 자금 이동에 대한 허용된 출처가 필요합니다. 은행 기록이나 해당 결제 사업자의 확인이 그것입니다. 고객 문서는 거래를 찾는 데 도움이 되지만, 장부에 돈을 자동으로 만들어 내서는 안 됩니다. 출처를 일시적으로 이용할 수 없다면 신청은 확인 대기 상태로 남아야 하며, 매니저의 요청으로 성공 처리되어서는 안 됩니다.

검증은 고유성을 고려해야 합니다. 금액, 날짜, 이름은 서로 다른 거래끼리도 겹칠 수 있습니다. 시스템은 은행 거래의 안정적인 식별자를 장부 기록과 연결하고, 눈에 띄지 않는 재사용을 허용하지 않습니다. 참조값이 고유하지 않거나 출처가 제공하지 않는다면 별도의 매칭 방법과 명시적인 불확실 상태가 필요합니다. UTR 필드가 채워져 있다는 이유만으로 통제가 충분하다고 선언해서는 안 됩니다.

두 번째 사례: 승인한 것과 보낸 것이 다르다

수취인 바꿔치기는 검토와 실행이 서로 다른 버전의 계좌 정보를 쓸 때 특히 위험합니다. 검토자가 고객에게 지급을 승인한 뒤 직원이 계좌를 수정했는데, 시스템이 기존 승인을 그대로 유지하는 경우입니다. 로그에는 서명이 두 개 있지만, 어느 것도 실제로 전송된 데이터와 관련이 없습니다.

OWASP는 거래 승인 권고에서 승인과 거래의 핵심 데이터 간 연결을 강조합니다. P2P 운영 설계에서 이는 승인이 특정 금액, 통화, 수취인, 지시 버전에 대해 이루어진다는 뜻입니다. 핵심 데이터가 바뀌면 새로운 결정이 필요합니다. 이는 일반 원칙을 적용한 제안이지, 모든 관리 화면에 그런 보호가 내장되어 있다는 주장이 아닙니다.

수취인 수정, 예외 허가, 지급 실행 권한은 분리합니다. 관리자에게도 로그를 소급해서 바꿀 무제한 권한을 주어서는 안 됩니다. 긴급 접근에는 제한된 작업, 사유, 기한, 독립적인 사후 검토가 필요합니다. 그렇지 않으면 긴급 버튼은 금세 통제 없이 일하는 일상적인 방법이 됩니다.

세 번째 사례: 두 사람도 짜고 칠 수 있다

한 트레이더가 아는 거래 상대방의 분쟁성 거래를 계속 승인하고, 한 검토자가 늘 예외를 허가한다면 표본 기반의 독립 점검을 할 이유가 됩니다. 하지만 비슷한 집중은 교대 일정, 언어 전담, 고정 포트폴리오 때문에도 생깁니다. 분석은 실제 업무를 배정 내역과 가능한 표본과 비교해야 합니다.

방어 신호는 조합을 중심으로 구성하는 것이 유용합니다. 비정상적으로 잦은 수동 수정, 실무자–검토자–수취인 관계의 반복, 계좌 정보 변경 후의 환불, 1차 증빙의 부재, 대사 이후 결과의 뚜렷한 차이 같은 것들입니다. 우회에 쓰일 임계값은 공개할 필요가 없습니다. 팀은 어떤 행동에 설명이 필요한지, 그리고 로그를 몰래 고칠 수 없다는 것만 이해하면 충분합니다.

검토자의 주기적 교체와 거래 종료 후 표본 점검은 특정 직원 두 명에 대한 의존도를 낮춥니다. 작은 팀이 거대한 보안 부서를 만들 필요는 없습니다. 같은 사람이 형식적으로 한 번 더 승인하는 것보다, 재무 통제 담당자가 가장 위험한 변경을 매일 독립적으로 살펴보는 편이 더 유용할 때가 있습니다.

삼각 사기는 익숙한 고객 그림을 깨뜨린다

삼각 사기가 의심될 때 돈, 신청, 추정 구매자는 서로 다른 사람에게 속할 수 있습니다. 방어 측면에서 중요한 것은 대화 내용으로 전체 수법을 짐작하는 것이 아니라 신원과 용도의 불일치를 알아차리는 것입니다. 금액과 입금 사실이 일치해도, 그 결제자가 자산을 받거나 게임 잔액을 충전받을 사람과 연결되는 것은 아닙니다.

신호는 해당 채널의 규칙과 함께 봅니다. 결제자 이름, 인증된 사용자, 지급 수취인, 확인된 용도, 변경 이력이 그것입니다. 필요 이상으로 새 정보를 요구하지 않고, 제3자의 서류를 공용 채팅에 모으지도 않습니다. 연결 관계가 설명되지 않으면 권한 범위 안에서 해당 거래의 실행을 보류하고 권한 있는 쪽으로 넘깁니다.

환불도 위험의 일부가 될 수 있습니다. 상대가 금액을 안다는 이유만으로 잘못 들어온 입금을 새 계좌로 돌려 달라는 요청을 처리해서는 안 됩니다. 요청자, 최초 자금 이동, 처분 권한, 허용되는 반환 채널을 확인합니다. 은행 제한이나 분쟁이 있다면 새로운 송금 사슬을 만들지 말고 은행과 정해진 절차를 통해 처리합니다.

직원 사냥 없는 조사

먼저 기록을 보존하고 위험한 특정 권한을 제한합니다. 그다음 독립 검토자가 사건을 재구성합니다. 누가 데이터를 봤는지, 무엇을 바꿨는지, 어떤 증거가 있었는지, 실제로 어떤 작업이 실행되었는지를 확인합니다. 조사 대상자에게 증거 추출을 단독으로 통제하게 해서는 안 됩니다. 동시에 조사 자료에 대한 다른 사람들의 접근도 제한합니다.

경영상 결정은 법적 판단과 분리합니다. 직원을 범죄자로 선언하지 않고도 수동 승인 권한을 일시적으로 회수할 수 있습니다. 고의가 증명되지 않더라도 발견된 인터페이스 결함은 고칩니다. 재무 손실은 확인된 자금 이동과 의무를 기준으로 계산하며, 같은 사건을 환불과 재지급으로 이중 계상하지 않습니다.

검토가 끝나면 구체적인 통제를 바꿉니다. 승인과 버전의 연결, 독립된 확인 출처, 수정 권한, 자금 이동 재사용 검사 같은 것들입니다. 비밀번호를 일괄 변경해도 한 지급을 승인하고 다른 지급을 보내는 논리적 허점은 사라지지 않습니다. 좋은 방어는 정당한 업무를 더 명확하게 만들고, 사람이 사실을 편리한 이야기로 몰래 바꿀 수 있는 틈을 줄입니다.