미션
뱅킹에서는 심사가 곧 제품입니다.
다른 분야에서는 먼저 출시하고 나중에 설명합니다. 금융 인프라는 정반대입니다. 증빙할 수 없는 기능은 존재하지 않는 것과 같고, 모든 기능은 실거래를 단 한 건 처리하기 전에 컴플라이언스 심사라는 관문을 반드시 통과해야 합니다.
그래서 첫 커밋부터 그 관문을 기준으로 설계합니다. 원장은 append-only 방식이며 1원 단위까지 정확히 대사됩니다. 모든 동의, 의사결정, 상태 변경은 감사인이 요구할 맥락과 함께 기록됩니다. PCI 범위는 의도적으로 최소화합니다. 가장 저렴한 통제는 설계 단계에서 없애 버린 통제이기 때문입니다.
그 결과 감사는 비상 대응이 아닌 형식적인 절차가 되고, '맞을 것 같습니다'라는 말은 '맞다는 증거가 여기 있습니다'로 바뀝니다.
프로젝트가 여기서 멈추는 이유
출시를 무너뜨리는 요인, 그리고 이를 설계로 피하는 방법.
- 분쟁 상황에서 대사할 수 없는 원장
- 스택 전반으로 번지는 PCI 범위
- 증빙 기록 없이 내린 의사결정
- 오픈 몇 주 전에 시작하는 컴플라이언스 사후 보완
- 설계 단계부터 1센트 단위로 정합을 맞추는 append-only 원장
- PCI 범위를 작게 유지하도록 격리한 카드 데이터
- 모든 의사결정과 동의를 발생 시점에 기록
- 사전에 모델링하고 문서화한 통제
역량
우리가 만드는 것
- 결제 게이트웨이 및 PSP 연동
- 매입사 및 카드 스킴 연결
- 토큰화 및 허가형 원장
- KYC / AML 온보딩 플로우
- 커스터디 및 키 관리
- 대사 및 정산
- 사기 탐지 및 리스크 스코어링
- 차지백 및 분쟁 처리
- PCI를 고려한 아키텍처
- 컴플라이언스 대시보드 및 리포팅
현장에서
컴플라이언스
심사에 가져가는 것
컴플라이언스 심사에 필요한 증빙 패키지를 개발과 함께 만들어 갑니다. 심사 일주일 전에 허둥지둥 끼워 맞추지 않습니다.
일하는 방식
플로우 맵에서 감사 통과까지.
- 01
맵
정상 경로, 실패, 환불, 분쟁까지 모든 자금·신원 흐름과 각 흐름에서 정합성이 유지되어야 하는 지점을 매핑합니다.
- 02
빌드
결제 레일, 원장, 온보딩을 첫 커밋부터 멱등성, 계측, 감사 대응을 갖추어 구축합니다.
- 03
검증
반드시 맞아야 하는 대사, 외부 검토, 프레임워크 기준으로 증빙한 모든 통제.
- 04
운영
실시간 정산·리스크 대시보드와 온콜 런북을 인수인계하거나 함께 운영합니다.
성과
작업이 가져다주는 결과
운영 환경까지 이끈 토큰화 자산 및 결제 레일 사례.
결제에서 '맞을 겁니다'는 답이 될 수 없습니다. 모든 거래, 모든 마감, 모든 감사에서 정합을 증명할 수 있는 시스템을 만듭니다.