세일즈 덱 · 기관용

Sales deck · for institutions

은행 · 금융사 · 페이사 · PG를 위한 PayChain V2PayChain V2 for banks, financial institutions, pay & PG companies

PayChain V2 = Payment + Settlement + Proof + Financial Execution Infrastructure. V2는 PX402·MCP·Agent SDK·ieum 통합·다중 네트워크 추상화를 메인 서사로 보여주고, V1.5의 Receipt SSOT·Batch·Anchor·Reconciliation·Institutional Governance는 그 밑바닥의 안정성 근거로 둡니다.

PayChain V2 = Payment + Settlement + Proof + Financial Execution Infrastructure. V2 is the main narrative — PX402, MCP, Agent SDK, ieum integration, and multi-network abstraction — while V1.5's Receipt SSOT, Batch, Anchor, Reconciliation, and Institutional Governance remain the trust kernel underneath.

여러 결제수단(스테이블코인·은행·카드·PG)의 거래를 하나의 정산·증빙 기록으로 묶어, 마감·대사·감사가 스스로 설명되게 만드는 정산 인프라입니다.

It ties transactions across rails (stablecoin, bank, card, PG) into one settlement and proof record, so close, reconciliation, and audit explain themselves.

1. 01

   PayChain V2: 결제·정산·증빙·금융 실행 인프라PayChain V2: Payment, Settlement, Proof, Financial Execution Infrastructure

   V2는 제품·앱·에이전트가 결제를 실행하고, V1.5 Settlement Kernel은 그 결과를 Receipt·Batch·Anchor·Proof로 검증 가능한 정산 상태로 만듭니다. 새 지갑도, 새 스테이블코인도, 코어·PG 대체도 아닙니다.

   V2 lets products, apps, and agents execute payments; the V1.5 Settlement Kernel turns those outcomes into verifiable settlement state via Receipt, Batch, Anchor, and Proof. Not a wallet, not a new stablecoin, not a core/PG replacement.

   Payments move money · Settlement creates trust · Execution creates value

2. 02

   문제

   Problem

   레일이 늘수록 정산·감사 줄기가 끊어진다As rails multiply, the settlement and audit trail breaks

   • 스테이블코인·은행·카드·PG가 각자 다른 시스템에서 정산되어 한 거래의 의미가 흩어집니다.
   • 온체인 transaction hash는 자산 이동의 증거일 뿐, 어떤 주문·계약·환불·세금인지는 설명하지 못합니다.
   • 환불·분쟁·수수료 조정·대사·감사가 수작업·별도 DB에 남아 재구성 비용이 큽니다.
   • Stablecoin, bank, card, and PG rails settle in separate systems, so the meaning of one transaction scatters.
   • An onchain transaction hash evidences asset movement but does not explain which order, contract, refund, or tax it is.
   • Refunds, disputes, fee adjustments, reconciliation, and audit live in manual steps and separate DBs, making reconstruction costly.
3. 03

   현상 유지의 비용

   Cost of inaction

   정산이 불투명하면 비용·리스크·도입 마찰이 누적된다Opaque settlement compounds cost, risk, and adoption friction

   대사 공수Reconciliation effort레일·파트너·통화별 수작업 증가manual work grows per rail, partner, currency

   감사 리스크Audit risk기간 거래를 사후 재구성reconstructing periods after the fact

   운영 단편화Operational sprawl레일마다 별도 연동·모니터링separate integration/monitoring per rail

   신뢰 비용Trust cost파트너·감사자에게 증빙 제출 어려움hard to give partners/auditors proof
4. 04

   해법

   Solution

   모든 레일을 하나의 Receipt 줄기로 정산·증빙한다Settle and prove every rail on one Receipt trail

   레일이 달라도 같은 흐름으로 맞춥니다:

   Different rails align to one flow:

   Receipt무엇what→ Batch언제·얼마when/how much→ Anchor변조 없음untampered→ Witness외부 검증external check

   기존 코어·PG·스테이블코인은 그대로 두고, 운영·정산·증빙 뷰만 통합합니다.

   Keep existing core, PG, and stablecoins — only the operations, settlement, and proof view is unified.

5. 05

   왜 지금인가

   Why now

   스테이블코인은 돈을 옮겼지만 운영을 끝내지 못했다Stablecoins moved money but did not finish operations

   • 스테이블코인 시장 약 $312.5B — 결제·송금·트레저리·B2B의 공통 레일로 확장 중.
   • 기관형 블록체인 정산이 현실화(예: J.P. Morgan Kinexys의 bank-led·permissioned 정산).
   • 애플리케이션·AI 에이전트가 자금을 실행하는 시대 — 정산·증빙이 선행되어야 안전합니다.
   • Stablecoins are a ~$312.5B market — a common rail for payments, remittance, treasury, B2B.
   • Institutional blockchain settlement is real (e.g., J.P. Morgan Kinexys' bank-led, permissioned settlement).
   • As apps and AI agents execute funds, settlement and proof must come first to stay safe.
6. 06

   어떻게 맞물리나

   How it fits

   PayChain V2 구조: 실행 레이어 위, 정산 커널 아래PayChain V2 architecture: execution layer above, settlement kernel below

   고객정보·권한·정산 책임 같은 민감 영역은 허가형(참여자가 통제되는) 신뢰 레이어에서, 정산 내역·증빙·시스템 연동은 개방형 실행 레이어에서 처리합니다. 민감정보는 공개하지 않으면서, 정산 결과는 외부에서 검증 가능 — 비공개 통제와 공개 검증을 동시에.

   Sensitive areas — customer data, permissions, settlement responsibility — sit in a permissioned (controlled-membership) trust layer; settlement detail, proof, and system integration sit in an open execution layer. Keep sensitive data private while settlement outcomes stay externally verifiable — private control and public verification at once.

   Product/App/Agent → PX402/API/MCP/SDK → Payment/Escrow/Evaluator → Receipt SSOT/Batch/Anchor/Proof → PayChain L2·PCI·외부체인

   Product/App/Agent → PX402/API/MCP/SDK → Payment/Escrow/Evaluator → Receipt SSOT/Batch/Anchor/Proof → PayChain L2, PCI, external chains

   Money · StablecoinPaymentSettlement · PayChainExecution · PX402Coordination · PCI
7. 07

   근거 (현 상태, 정직하게)

   Proof (honest status)

   ieum PoC와 정산 커널로 검증된 구조Validated by the ieum PoC and settlement kernel

   • 정산 파이프라인이 실제로 동작합니다 — 거래 기록 → 정산 묶음 → 위·변조 불가 증빙 → 외부 검증, 그리고 승인(4-eyes)·감사·대사까지.
   • ieum on PayChain L2 PoC — chainId 42472 위 KSC·StableVault·PaymentManager, 이중승인 발행, 가맹점 정산, Receipt 등록, Batch/Anchor, Merkle 증명까지 검증된 사례를 세일즈 근거로 사용합니다.
   • 기존 Avalanche/XRPL 흐름은 회귀 없이 유지하고, NetworkRegistry로 PAYCHAIN을 정식 NetworkType에 편입한 다중 네트워크 추상화를 확인했습니다.
   • 자동 검증(품질 게이트) 20/21 통과, 데모 환경에서 전 과정 시연 가능.
   • 공개 상태 페이지에서 “지금 실거래(live)인지, 테스트(mock)인지”를 누구나 확인 — 숨기지 않습니다.
   • 현재 파일럿 단계: 실 블록체인 앵커·운영 권한(API 키)·실 PCI 연동은 로드맵으로 명시하며 과장하지 않습니다.
   • The settlement pipeline actually runs — transaction record → settlement batch → tamper-evident proof → external verification, plus approvals (4-eyes), audit, and reconciliation.
   • ieum on PayChain L2 PoC — on chainId 42472: KSC, StableVault, PaymentManager, dual-approval issuance, merchant settlement, Receipt registration, Batch/Anchor, and Merkle proof were validated as sales proof.
   • Existing Avalanche/XRPL flows remained regression-free while PAYCHAIN was added as a first-class NetworkType through NetworkRegistry.
   • Automated quality gates 20/21 passing; the full flow is demonstrable in a sandbox.
   • A public status page lets anyone confirm whether it is live or test (mock) right now — nothing hidden.
   • Pilot stage today: live blockchain anchoring, production access keys, and real PCI integration are stated as roadmap, no overclaim.
8. 08

   ROI · 비즈니스 케이스

   ROI · business case

   통합 비용↓ · 정산 설명력↑ · 감사 준비 상시화Lower integration cost, explainable settlement, always-audit-ready

   통합 비용Integration레일별 중복 연동 → 단일 Receipt APIper-rail duplication → one Receipt API

   대사 시간Reconciliation사후 수작업 → 네트워크 레벨 자동화manual → network-level

   감사 대응Audit재구성 → Anchor·Witness 상시 증빙reconstruct → standing Anchor/Witness proof

   분쟁·환불Dispute/refund예외 → 추적 가능한 상태 전이exception → traceable state transition

   ※ 수치형 ROI는 파일럿 데이터(거래량·대사 공수·인시던트)로 함께 산출합니다 — 가정·민감도 포함.

   Note: quantified ROI is built together from pilot data (volume, reconciliation effort, incidents) — with assumptions and sensitivity.

   대사 효익 추정기 (귀사 입력값 기반)Reconciliation value estimator (your inputs)

   월 거래 건수Transactions / month 수작업 대사 비율 (%)% needing manual recon 건당 처리 시간 (분)Minutes per item 인건비 (시간당, 원)Loaded cost / hour 예상 절감률 (%)Expected reduction (%)

   월 절감 시간Hours saved / month—

   연간 절감액 (추정)Annual savings (est.)—

   교육용 추정치입니다. 입력 가정에 따라 달라지며, 실제 ROI는 파일럿 데이터로 함께 확정합니다.

   Illustrative estimate driven by your inputs. Actual ROI is confirmed together from pilot data.

9. 09

   신뢰 · 컴플라이언스 팩

   Trust · compliance pack

   권한·증빙·키 관리가 설계의 일부Permissions, proof, and key management are part of the design

   • RBAC: 공개 read / operator·batcher·auditor 키로 write 보호.
   • 4-eyes 정책: 승인·재처리·동결 훅, 인바리언트·대사 검사.
   • Anchor/Witness 감사: 변조 불가 증거 + 외부 검증, mock/live 투명 노출.
   • Signer 분리: HMAC·IP allowlist·KMS(opt-in), 키 로테이션·인시던트 런북.
   • RBAC: public reads / writes protected by operator, batcher, auditor keys.
   • 4-eyes policy: approval, reprocess, freeze hooks; invariant and reconciliation checks.
   • Anchor/Witness audit: tamper-evident proof + external verification; transparent mock vs live.
   • Signer isolation: HMAC, IP allowlist, KMS (opt-in); key rotation and incident runbook.
10. 10

    도입 경로 (30 / 60 / 90)

    Rollout (30 / 60 / 90)

    샌드박스 → 파일럿 → 라이브, 낮은 리스크로Sandbox → pilot → live, with low risk

    30샌드박스·기술 검토 — API·Receipt 흐름, 보안 1-pager, 범위 합의Sandbox + tech review — API/Receipt flow, security one-pager, scope

    60파일럿 — 한 레일/한 정산 흐름에 KPI·증빙, Postgres·테스트넷 앵커Pilot — one rail/flow with KPIs and proof, Postgres + testnet anchor

    90라이브 확장 — RBAC 키, 라이브 앵커, 대사·감사 운영 전환Live expansion — RBAC keys, live anchor, reconciliation/audit ops
11. 11

    이해관계자별 가치

    Value by stakeholder

    한 네트워크, 역할마다 다른 이유One network, a different reason per role

    재무 · 트레저리Finance · Treasury정산 설명력·대사 자동화·현금흐름 가시성explainable settlement, auto-reconciliation, cash visibility

    기술 · 엔지니어링Tech · EngineeringEVM·API·SDK, 멱등·webhook, 단일 Receipt 연동EVM/API/SDK, idempotency/webhooks, one Receipt integration

    컴플라이언스 · 감사Compliance · AuditRBAC·4-eyes·Anchor/Witness 증빙·키 관리RBAC, 4-eyes, Anchor/Witness proof, key mgmt

    운영 · PGOps · PGBatch 단위 정산·payout, 환불·분쟁 추적batch settlement/payout, refund/dispute tracking
12. 12

    대안 대비

    Versus alternatives

    왜 직접 구축·범용 체인이 아니라 PayChain인가Why PayChain, not in-house or a generic chain

    접근Approach	정산·증빙Settle & prove	멀티레일 통합Multi-rail	감사 추적Audit trail	기존 시스템 유지Keep systems
    직접 구축(사내 대사)In-house reconciliation build	△	△	△	○
    범용 스테이블코인 체인Generic stablecoin chain	✕	✕	✕	△
    PG·코어뱅킹 단독PG / core banking alone	△	✕	△	○
    범용 L2·롤업Generic L2 / rollup	✕	△	✕	△
    PayChain	○	○	○	○

    직접 구축은 가능하지만 정산·증빙·감사를 처음부터 만들고 유지해야 합니다. 범용 체인·L2는 빠른 전송엔 강해도 금융 상태·증빙에 특화되지 않습니다. PayChain은 라이브 항목을 정직하게 로드맵으로 표기합니다.

    In-house is possible but you build and maintain settlement, proof, and audit from scratch. Generic chains/L2s are great at fast transfer but not specialized for financial state and proof. PayChain labels live items honestly as roadmap.

13. 13

    다음 단계 (Mutual Action Plan)

    Next step (Mutual Action Plan)

    2주 안에 샌드박스, 그다음 범위 합의된 파일럿Sandbox within two weeks, then a scoped pilot

    1. 소개 콜 + 보안 1-pager·ROI 모델 공유
    2. 샌드박스 접속 — Receipt → Batch → Anchor 흐름 확인
    3. 파일럿 범위·KPI·담당자·일정 합의 (MAP)
    1. Intro call + share security one-pager and ROI model
    2. Sandbox access — walk the Receipt → Batch → Anchor flow
    3. Agree pilot scope, KPIs, owners, and dates (MAP)
    파일럿 시작하기Start a pilot 배경 아티클 5부작Read the 5-part series

이 덱은 파트너·기관 검토용 자료입니다. 구현 상태는 공개 network-activation-status로 상시 확인 가능하며, 미완 항목은 로드맵으로 명시합니다.

This deck is for partner and institutional review. Implementation status is always verifiable via the public network-activation-status; roadmap items are labeled as such.