Wave G: 실제 매입사 경제모델 고도화 (딥리서치 갭분석 기반)

딥리서치(95 에이전트, OCC/Fed/Berlin Group 등 1차 출처, 검증된 9 finding)로
실제 카드 매입사 아키텍처를 조사(docs/GAP_ANALYSIS.md)하고, 최우선 갭 3개를
스키마+시드+런타임서비스+화면으로 메웠다.

메운 갭 (실제 매입사 핵심 메커니즘)
1. 수수료 3층 분해: 기존 flat MDR → interchange(발급사)+scheme fee(카드망)+
   markup(매입사 수익). 실측 결과 interchange=MDR의 86% (리서치 "70~90%"와 일치).
2. 클리어링 ≠ 정산 분리: 승인·정산과 별도인 프레젠트먼트(클리어링) 단계 추가.
3. 발급사↔매입사 순액정산: BIN/ICA 기준 다자 순액(한국 BC카드 컨소시엄형).
4. 펀딩 항등식: 총매출−환불−채그백−수수료−리저브=입금 (2,924건 전부 항등 성립).
5. 채그백/분쟁 라이프사이클: FIRST_CB→REPRESENT→PRE_ARB→ARBITRATION 상태기계.

스키마 (db/schema.d/70-econ.sql, 96-econ-seed.sql)
- 신규 9테이블: st_interchange_rate, st_scheme_fee, st_fee_component, cl_presentment,
  st_member_bank, st_net_settlement, st_reserve, st_merchant_funding, ac_dispute.
- 기존 정산건 소급 분해(요율표 카드종류×채널 차등) + 순액정산 배치 + 펀딩 계산.
- 시드 계산검증: 3층 항등식·펀딩 항등식 100% 성립(내가 채그백 일수중복 버그 1건 수정).

런타임 서비스 (전부 게이트웨이로 실호출 검증)
- st: ST_FEEDECOMP(ic+sf+markup=mdr), ST_NETSETTLE(BIN별 순액), ST_FUNDING(항등식)
- ac: ACQ_DISPUTE_OPEN, ACQ_DISPUTE_ADVANCE(상태기계-부적법 전이 거부),
  ACQ_PRESENT(클리어링). 각 120줄+, ECPG/XA 격리 규율 준수.

화면 (포털 AR0003 "정산 경제", #econ)
- 수수료 3층 색상바 + 펀딩 항등식 워터폴 + 발급사별 순액정산 + 분쟁 라이프사이클
  + 클리어링. 전부 실측 데이터 조회.

검증
- 통합 빌드 error 0, 도메인 재기동 5,879 서비스 AVAIL
- 6개 신규 서비스 실호출 정상(수수료 3층 84=74+6+4, 상태기계 부적법 전이 거부)
- 기존 6단 매입 체인 COMMIT OK 유지, 미결 2PC 0

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
hyeongwoo 2026-07-22 14:03:35 +09:00
parent 46ff41b633
commit 438ae8992d
20 changed files with 1500 additions and 4 deletions

45
docs/GAP_ANALYSIS.md Normal file
View file

@ -0,0 +1,45 @@
# 실제 매입시스템 vs acquire-core-x — 갭 분석
> 딥리서치(1차 규제·표준 출처 기반, 검증된 9개 finding)로 확인한 **실제 카드 매입사
> 아키텍처**를 우리 구현과 대조한다. 목적: 리얼리티 갭을 찾아 고도화 우선순위를 정한다.
> 출처: OCC Merchant Processing Handbook, Fed Philadelphia clearing&settlement paper,
> Berlin Group ISO 8583, Marqeta/Checkout/Stripe, BC Card.
## 핵심 대조 (검증된 실제 메커니즘 → 우리 현황)
| # | 실제 매입시스템 메커니즘 (검증됨) | 우리 현황 | 갭 |
|---|---|---|---|
| 1 | **Clearing ≠ Settlement.** 승인은 권한/홀드일 뿐 돈이 안 움직인다. 클리어링=상세 거래데이터 교환(발급사↔매입사 채무 확정), 정산=그 채무를 실제 자금이동으로 해소. | 승인(au)·정산(st)은 있으나 **클리어링(프레젠트먼트) 단계가 통째로 없음**. 정산이 곧 자금이동으로 뭉뚱그려짐. | 🔴 **대** |
| 2 | **이중메시지 vs 단일메시지.** 신용/서명체크=승인과 클리어링 분리(EDC 배치 캡처 후 일 1회+ 제출, 프레젠트먼트 윈도우). PIN/ATM=승인+클리어링 1회 통합. | 채널(POS/EDC/EDI/FOREIGN)은 있으나 **이중/단일 구분·프레젠트먼트 윈도우 없음**. | 🟠 중 |
| 3 | **ISO 8583 클리어링 메시지 클래스.** presentment / chargeback / fee-collection / reconciliation / file-rejection 이 별도 기능. | mg 모듈에 채널·라우팅·큐는 있으나 **클리어링 메시지 클래스 모델 없음**. MTI 언급은 있음. | 🟠 중 |
| 4 | **BIN/ICA 기준 순액정산.** 정산은 매입사 스킴 회원식별자(Visa=BIN, MC=ICA)로 라우팅, 은행별 차대변 합산 후 **단일 순액**을 정산은행 통해 이체. | 정산이 **가맹점 단위**로만 계산됨. **발급사↔매입사 순액정산(net settlement) 계층 없음**. | 🔴 **대** |
| 5 | **수수료 3층 분해.** MDR = interchange(발급사, 최대·일단위 순정산시 징수) + scheme fee(카드망) + acquirer markup(매입사 마진, 유일한 협상대상, 월청구). 요율은 카드종류·MCC·거래유형·채널·사기율에 따라 변동. | **flat MDR 하나**(`fee = amount × mdr_bps`). interchange·scheme fee·markup 분해 **전무**. | 🔴 **대(최우선)** |
| 6 | **Interchange qualification.** 데이터 품질/채널/카드종류로 interchange 등급(tier)이 갈림. | mm_fee_rate 가 merchant×card_type 단일요율. **MCC·채널·등급 차등 없음**. | 🟠 중 |
| 7 | **정산·펀딩 항등식.** 총매출 환불 채그백 처리수수료 롤링리저브 = 예상 입금액. | 정산은 net 만. **환불·채그백·리저브를 반영한 펀딩 계산 없음**. | 🔴 **대** |
| 8 | **채그백/분쟁 라이프사이클.** 1차 채그백 → representment(재청구) → pre-arbitration → arbitration, reason code 체계. | chargeback/dispute 언급 일부(테이블 없음), **representment·중재 단계 없음**. | 🟠 중 |
| 9 | **한국 BC카드형 다자간 순액정산.** 회원은행 간(카드소지자 은행↔가맹점 은행) 다자간 순액정산 = 공유 클리어링/정산망(밴사/VAN). | 발급사(issuer) 값은 있으나 **회원사간 다자정산 계층 없음**. | 🟠 중 |
## 고도화 우선순위 (리얼리티 임팩트 순)
**🔴 1순위 — 수수료 3층 분해 + 정산 항등식 (매입사 경제모델의 핵심)**
- interchange(발급사 귀속) / scheme fee(카드망) / acquirer markup(매입사 마진) 분리
- 요율표: 카드종류 × MCC × 채널 × 거래유형 차등 (interchange qualification)
- 정산 항등식: 총매출 환불 채그백 수수료 리저브 = 가맹점 입금
- 이게 있어야 "이 시스템이 실제로 돈을 어떻게 나누는지" 설명됨
**🔴 2순위 — 클리어링 ≠ 정산 분리 + 순액정산**
- 승인 → 캡처 → **프레젠트먼트(클리어링)****순액정산** → 가맹점 펀딩 을 별도 단계로
- 발급사↔매입사 순액정산(net settlement), BIN/ICA 라우팅
- 한국형: 회원사간 다자 순액정산(밴사/VAN)
**🟠 3순위 — 채그백/분쟁 라이프사이클 + ISO 8583 클리어링 메시지**
- dispute 상태기계: 1차CB → representment → pre-arb → arbitration + reason code
- mg에 클리어링 메시지 클래스(presentment/chargeback/fee-collection/recon/reject)
## 설계 방침
- **기존 구조를 깨지 않는다.** 신규 테이블·서비스를 추가하고, 기존 flat MDR 는 markup 으로
재해석해 하위호환. 6단 XA 체인·477 tpcall 체인은 유지.
- **오너-라이츠·XA 브랜치 격리 규율** 그대로 적용 (Wave F 교훈).
- **실측 데이터로 시드**: interchange 요율표(카드종류×MCC×채널), 프레젠트먼트/클리어링 이력,
채그백 케이스, 순액정산 배치 결과.