지불이 빠를수록 왜 더 많은 신용이 필요할까요?

저자：Steven，Payment 201

지불 산업에는 명백하면서도 많은 사람들이 간과하는 시간 차이가 있습니다. 하나의 Merchant의 자금은 T+1이 되어야 진정한 정산이 이루어지지만, Recipient는 오늘 바로 입금을 요구합니다; 하나의 Marketplace가 소비자 수금을 완료했지만, Seller는 이미 출금을 클릭했습니다; 한 Cross-border Payment Company가 미국에서 USD를 수령했지만, 멕시코의 Beneficiary는 몇 초 후에 MXN을 받기를 원합니다.

사용자의 관점에서 보면, 이러한 일들은 매우 간단합니다: Payment completed.

하지만 Treasury와 Balance Sheet의 관점에서 보면, 문제는 완전히 다릅니다: 돈이 아직 도착하지 않았는데, 왜 이미 지불할 수 있습니까? 이 몇 시간, 심지어 하루의 돈은 도대체 누구의 돈입니까?

가장 직접적인 대답은 물론 Payment Company가 먼저 자금을 지불하는 것입니다. 만약 자금이 내일 진정으로 도착한다면, PSP가 오늘 Corporate Cash에서 Payout을 완료한 것은 우선 Self-funded Prefunding입니다: PSP는 자신의 Balance Sheet로 Timing Gap을 흡수했습니다.

하지만 여기에는 자주 혼동되는 두 가지 문제가 있습니다.

첫째, PSP가 자신의 돈으로 먼저 지불한다고 해서 자동으로 법적 또는 제품적 의미에서 고객에게 "대출을 제공했다"고 할 수는 없습니다. Treasury의 관점에서 보면, 이는 우선 Balance Sheet Usage와 Funding Exposure를 나타냅니다.

둘째, 더 현실적인 문제는:

PSP는 매일 많은 돈을 다루지만, 이 돈이 모두 선불로 사용할 수 있다는 것을 의미하지는 않습니다.

Customer Funds, Corporate Cash 및 Credit Capacity는 세 가지 완전히 다른 것입니다. Payment가 일정 규모에 도달하면, Credit이 점차 Financial Product에서 Payment Infrastructure의 일부로 변하는 본질은 이 세 가지 숫자가 점점 더 맞지 않게 되기 때문입니다.

일, PSP가 많은 돈을 다룬다고 해서 이 돈을 선불로 사용할 수 있는 것은 아니다

이 점은 상장된 결제 회사의 자산 부채표에서 매우 직관적으로 볼 수 있습니다.

연연 디지털을 예로 들어보면, 2025년 전체 Global Payment TPV는 4,524억 위안에 도달하여 전년 대비 60.7% 증가했습니다.

하지만 Balance Sheet를 계속 살펴보면, 2025년 말 기준으로 회사의 현금 및 현금성 자산은 약 16.28억 위안이며, Total Equity는 약 30.72억 위안입니다; 동시에, Customer Segregated Funds는 약 194.66억 위안입니다.

이 숫자들을 함께 놓고 보면, 가장 직관적으로 설명하는 것은:

Customer Funds와 Corporate Liquidity는 두 가지 다른 것입니다.

Payment Company는 매년 수천억, 수조 원의 자금을 처리할 수 있지만, 연간 TPV와 동일한 규모의 Own Balance Sheet를 가질 필요도 없고, 가질 수도 없습니다. 이는 본래 Payment Business가 Scale할 수 있는 기반입니다.

하지만 다른 한편으로, Payment Obligation과 Cash Arrival이 어긋나면, 실제로 선불로 지불할 수 있는 것은 플랫폼이 "다루는 모든 돈"이 아닙니다.

오히려:

자신의 Corporate Liquidity와 미리 준비된 External Funding Capacity입니다.

연연은 동기에도 약 14.07억 위안의 미사용 은행 신용 한도를 공개했습니다. 물론, 이는 이러한 Credit Line이 반드시 Payment Prefunding에 사용된다는 것을 의미하지는 않지만, 이는 또 다른 Financial Capacity의 층을 잘 설명합니다:

Payment Company가 실제로 호출할 수 있는 자금 능력은 단순히 장부상의 현금만으로는 충분하지 않습니다.

그래서 결제 산업에서는 세 가지 숫자가 특히 혼동되기 쉽습니다:

• Customer Funds는 당신이 관리하는 돈의 양을 결정합니다.

• Own free Cash는 당신이 선불로 사용할 수 있는 돈의 양을 결정합니다.

• Credit Capacity는 Own free Cash가 부족할 때, 당신이 계속 약속할 수 있는 돈의 양을 결정합니다.

세 번째 층이야말로 이 글이 진정으로 논의하고자 하는 것입니다.

이, 돈이 아직 도착하지 않았는데, 왜 이미 지불할 수 있습니까?

가정해 보십시오, 하나의 Marketplace가 오늘 오전 10시에 Seller에게 1억을 지불해야 하지만, 해당 Consumer Funds는 오후나 심지어 다음 날에야 진정으로 사용 가능해집니다(수수료 정산 주기, 비즈니스 구조 C2B2B2C/B 구조 배치, 은행 심사 효율성 등 다양한 이유로 인해 발생할 수 있습니다).

제품 페이지에서 보면, 이는 단순한 Payout입니다.

하지만 오전 10시부터 플랫폼은 1억 Payment Obligation을 형성했지만, 이 Obligation에 해당하는 Cash는 아직 자유롭게 사용할 수 있는 상태에 들어오지 않았습니다.

그래서 중간에 나타나는 것이:

Funding Gap.

만약 Marketplace가 기다리기로 선택한다면, 이 시간은 Seller가 부담하게 됩니다------돈이 언제 진정으로 사용 가능해지는지, 언제 지불할지.

하지만 제품이 T+0, Same-day, 심지어 Instant Payout을 약속한다면, 플랫폼은 실제로 Seller의 몸에서 이 기다리는 시간을 적극적으로 빼앗고 있는 것입니다.

문제는 사라지지 않았습니다. 시간은 단지 다른 사람이 부담하게 된 것입니다.

가장 간단한 해결책은 플랫폼이 먼저 지불하는 것입니다. Corporate Cash가 충분하다면, 오늘 Payout을 완료하고, 내일 해당 자금이 도착한 후 다시 자신의 Cash Position을 회복합니다.

이는 우선 Balance Sheet Decision입니다.

플랫폼은 자신의 Capital을 사용하여 더 나은 Payment Experience를 얻기로 선택합니다.

규모가 작을 때는 이 일이 Credit의 존재를 느끼지 못할 수도 있습니다. Treasury가 조금 더 Buffer를 두면, 아마도 해결될 수 있습니다.

하지만 매일의 Payment Volume이 10m에서 100m로, 다시 1bn으로 변하면, 같은 하루 Timing Gap이 필요로 하는 자금은 빠르게 확대됩니다.

더 중요한 것은, PSP가 돈이 있다고 해서 장기적으로 이렇게 하는 것이 좋은 Capital Allocation이라는 것을 의미하지는 않습니다.

일 년에 몇 번 발생할 수 있는 Peak Volume에 대응하기 위해, 영구적으로 계좌에 몇 억 원의 현금을 더 두는 것은 본래 매우 비싼 Opportunity Cost입니다.

그래서 문제는 곧 다음과 같이 변합니다:

Own free Cash가 부족하거나, Own free Cash를 계속 사용하는 것이 전혀 가치가 없다면, 어떻게 해야 합니까?

하나의 선택은 Payment Experience를 축소하는 것입니다.

Payout을 지연시키고, Prefunding Requirement을 높이며, Volume Limit을 낮추고, 극단적인 경우 일부 Payment를 일시 중지하는 것입니다.

다른 선택은:

다른 Balance Sheet를 찾는 것입니다.

은행 신용 한도, 오버드래프트, 일일 시설, 정산 금융, 개인 신용……

그래서 Payment와 Credit이 처음 만나는 것은 PSP가 대출 제품을 출시한 것이 아닙니다.

오히려:

Payment가 시간을 초월하기 시작했습니다.

삼, Liquidity와 Credit, 도대체 무엇이 다릅니까?

여기서는 Liquidity와 혼동하기 쉽습니다.

가정해 보십시오, 멕시코가 오늘 20m MXN이 필요하지만, Local Account에는 5m만 있습니다. 만약 그룹의 홍콩 계좌에 충분한 USD가 있고, 지금 FX를 완료할 수 있으며, 해당 MXN Position을 멕시코로 조정할 수 있다면, 이는 우선: Liquidity Management입니다.

Corporate Balance Sheet는 그로 인해 커지지 않습니다. 돈은 단순히 하나의 Currency, Location 및 Position에서 다른 Position으로 조정된 것입니다.

Liquidity는 기존 자원을 어떻게 조정할지를 해결합니다.

하지만 그룹의 모든 현재 호출 가능한 Own Liquidity를 합쳐도 80m만 제공할 수 있고, 오늘 이미 100m Payment Obligation이 형성되었다면, 남은 20m은 단순히 돈을 A에서 B로 옮기는 것으로 해결할 수 없습니다.

이제 진짜 문제는:

이 Gap을 어디서 메울 것인가?

회사는 물론 영구적으로 20m Cash를 더 준비할 수 있지만, 이는 여전히 Self-funded입니다.

하지만 모든 가능한 Peak Demand를 위해 영구적으로 자신의 Capital을 점유하고 싶지 않다면, 은행, 신용 제공자 또는 기타 Capital Provider가 추가 Funding Capacity를 제공해야 합니다.

그래서 더 정확한 관계는 단순히:

Liquidity → Credit.

이 아니라:

Liquidity는 기존 자원을 어떻게 사용할지를 해결합니다.

Funding은 Gap을 어디서 메울지를 해결합니다.

Credit은 추가 Funding Capacity를 얻는 중요한 방법 중 하나입니다.

이 구분은 매우 중요합니다. 왜냐하면 Self-funded Prefunding 자체가 Borrowing과 같지 않으며, PSP가 고객에게 Credit Product를 제공했다는 것을 의미하지 않기 때문입니다.

하지만 Payment Scale이 점점 커질수록, 항상 Own free Cash에 의존하여 모든 Peak Demand를 충족시키는 것은 Capital Efficiency가 점점 나빠질 것입니다.

이때 Credit이 실제로 제공하는 것은 단순히 "당신에게 돈을 더 빌려주는 것"이 아닙니다.

오히려: Elasticity입니다.

Liquidity는 기존의 Money가 어떻게 사용되는지를 결정합니다. 그리고 Credit은 기존 Money가 부족할 때: Capacity가 임시로 커질 수 있는지를 결정합니다.

사, Instant Payment의 경험, 많은 경우 Balance Sheet가 백그라운드에서 비용을 지불합니다

지난 10년 동안, Payment Industry는 한 가지 일을 해왔습니다: 돈을 점점 더 빠르게 만들기. T+3, T+2, T+1, Same-day, T+0, 오늘날 점점 더 많은 Instant가 사용자 경험의 관점에서 보면, 이는 분명한 진화 경로입니다.

하지만 금융 인프라에는 매우 직관에 반하는 문제가 있습니다:

Recipient가 돈을 받는 속도가 빨라진다고 해서 Upstream Cash Arrival도 동일하게 빨라진다는 것을 의미하지는 않습니다.

과거 Merchant는 T+1로 돈을 받았고, 동시에 PSP도 T+1로 해당 정산을 받았으며, 양쪽의 시간은 대략 일치했습니다. 오늘날 경쟁을 위해 플랫폼은 Merchant Payout을 T+0으로 앞당겼습니다. 하지만 만약 기본 정산이 여전히 T+1이라면, 원래 존재하지 않았던 하루 Funding Gap이 발생하게 됩니다.

그래서 업계는 표면적으로 정산 시간을 계속 없애고 있습니다. 사실, 많은 경우 이 시간은 Customer Experience에서 제거되고, Financial Institution의 Balance Sheet로 옮겨집니다.

Instant Payment의 사용자 경험은, 많은 경우 Balance Sheet가 백그라운드에서 비용을 지불하는 것입니다.

Payment가 실시간으로 이루어질수록, Timing Risk는 공중에서 사라지지 않습니다. 단지 재분배될 뿐입니다. Seller는 기다리지 않고, Platform이 기다립니다. Merchant는 기다리지 않고, Acquirer가 기다립니다. Client가 Prefund를 원하지 않으면, PSP는 결정해야 합니다: 스스로 부담할 것인지, 다른 사람에게 부담할 것인지.

이 논리는 현재 심지어 제품으로 직접 만들어지고 있습니다.

예를 들어 YouLend의 Instant Settlement / Instant Payout은 본질적으로 Sale이 이미 발생했지만, 정상적인 정산이 아직 완전히 완료되지 않았을 때 Merchant가 Receivable에 해당하는 자금을 더 일찍 받을 수 있게 하는 것입니다.

이는 사실 글의 시작 부분에서 언급한 문제의 제품화입니다:

Sale happened, Cash hasn't fully followed.

하지만 Merchant는:

Gets paid anyway.

원래 기다려야 했던 그 시간은 Financing에 의해 소모되었습니다.

Stablecoin 역시 이 문제를 자동으로 해결하지 않습니다.

Blockchain은 24/7 Transfer가 가능하지만, Fiat Banking, FX, Redemption, Local Clearing 및 전통적인 Funding Market은 반드시 24/7로 동기화되지 않습니다.

그래서:

24/7 Settlement ≠ Zero Funding Requirement.

심지어 반대로 생각해 볼 수 있습니다. 과거에는 돈이 토요일에 이동할 수 없었고, 사용자는 기본적으로 월요일까지 기다렸습니다. 미래에는 Rail이 토요일 새벽에도 Instant Settlement가 가능하다면, 또 다른 문제가 즉시 발생합니다:

토요일 새벽에 그 Liquidity와 Funding은 어디서 오는가?

Rail이 더욱 실시간으로 진행될수록, 백엔드 팀은 단순히 "돈이 도착할 때까지 기다리세요."라는 말로는 안 됩니다.

오, Payment Scale의 마지막은 Credit Elasticity

매일 1m Volume 중 10%가 몇 시간의 Timing Gap이 존재한다면, 임시로 100k를 커버하면 됩니다. 매일 1bn의 경우, 동일한 10%의 Timing Mismatch는 100m입니다.

하지만 실제 Payment Network는 결코 매일 부드러운 곡선에 따라 운영되지 않습니다.

Payday, 대촉진, 은행 휴일, 주말, FX 변동성, 정산 지연, 은행 중단 등은 특정 시장에서 몇 시간 내에 정상 수준을 훨씬 초과하는 Payment Obligation을 형성할 수 있습니다.

따라서 대형 PSP는 단순히 역사적인 최대 Peak에 따라 수십 개 시장에 영구적으로 Cash를 쌓아둘 수 없습니다.

이론적으로는 안전하지만, 경제적으로는 극히 비쌉니다.

성숙한 Payment Network에서 자금 능력은 결국 Layered Capacity로 변하게 됩니다.

정상적인 Flow는 Natural Flow, Netting 및 Own Liquidity를 통해 소화할 수 있습니다; 일반적인 변동은 Treasury Buffer가 부담합니다; 더 큰 Gap이 발생할 때는 Bank Credit Line, Overdraft, Intraday Facility, 심지어 Settlement Financing 또는 기타 External Funding을 호출하기 시작합니다.

따라서 규모가 진정으로 커지면, Payment Network가 필요로 하는 것은 단순한 고정 Liquidity Pool이 아닙니다. 오히려: Credit Elasticity입니다.

Liquidity Capacity는 정상적인 상황에서 오늘 내가 얼마나 지불할 수 있는지를 대답합니다. Credit Elasticity는 오늘 갑자기 비정상적일 때, 내가 얼마나 더 지불할 수 있는지를 대답합니다.

이것이 Huma/Arf, MANSA와 같은 플레이어가 주목할 만한 이유입니다.

그들이 진정으로 변화시키고자 하는 것은 Payment Rail이 아니라, Payment Network 뒤에 있는: Capital Deployment Model입니다.

과거에는 더 많은 것이: Pre-positioned Capital. Treasury가 먼저 돈을 빌리고, 먼저 돈을 조정하고, 각 시장에서 Balance를 준비한 다음, Payment System이 이러한 Position을 소모하기를 기다립니다.

하지만 Huma/Arf, MANSA가 대표하는 방향은 다음과 더 가깝습니다:

Payment 발생 → Liquidity / Credit 호출 → Settlement 완료 → Capital 회수.

즉:

On-demand Financial Capacity.

Huma와 Arf가 합병한 후, 핵심 시나리오 중 하나는 Cross-border Payment Financing로, on-demand liquidity를 통해 일부 Payment Institution의 정적 Prefunding 의존도를 낮추는 것입니다; MANSA는 PSP, EMI, Remittance 등 기관을 대상으로 Settlement-time Liquidity를 직접 제공합니다.

내가 가장 주목해야 할 것은, 이러한 회사들이 Stablecoin을 사용했는지가 아닙니다.

오히려:

Credit Capacity가 정적 존재에서 동적 호출로 이동하기 시작했습니다.

이 모델이 더 확장될 수 있다면, 변화시키는 것은 Funding Cost뿐만 아니라 전체 Treasury Architecture입니다. Payment Company는 모든 가능한 Demand를 위해 모든 Corridor에 영구적으로 동일한 규모의 Cash를 준비할 필요가 없습니다.

Own free Cash는 당신에게 기본 Capacity를 제공하고, Credit는 당신에게 Elasticity를 제공합니다.

육, 왜 Payment Flow를 장악한 회사가 자연스럽게 Credit로 나아가게 되는가?

앞서 언급한 것은: Credit for Payment, 즉 Credit이 어떻게 Payment Flow를 지원하는가입니다.

하지만 Payment와 Credit 사이에는 또 다른 방향이 있습니다:

Credit from Payment.

이것은 Stripe, Adyen, PayPal, Block과 같은 Payment Flow를 장악한 플랫폼이 Merchant Financing과 Working Capital을 자연스럽게 발전시키는 이유를 설명합니다.

사실 그 이유는 복잡하지 않습니다.

전통적인 대출자는 Underwriting을 수행하기 위해 회사의 수익, Cash Flow, 계절성, 성장, 고객 집중도 및 미래 상환 능력을 이해해야 합니다.

Payment Company는 매일 이러한 정보를 보고 있습니다. TPV, 거래 빈도, 평균 티켓 크기, 환불, Chargeback, 판매 추세, 계절성…… 계좌 및 정산 관계와 결합하면, Cash Inflow, Cash Outflow, 계좌 잔액, 공급자 지불 및 Working Capital Cycle까지 더 나아가 볼 수 있습니다.

이것들은 기업이 연간 제출하는 Financial Statement가 아닙니다.

오히려 지속적으로 발생하는:

Real-time Business Activity.

따라서 Payment Data는 자연스럽게:

Underwriting Data.

하지만 Payment Company가 Credit에서 진정으로 특별한 점은 단순히 Data가 더 많다는 것이 아닙니다.

더 중요한 것은:

많은 경우 Cash Flow를 통제하기도 한다는 것입니다.

가정해 보십시오, Merchant가 매일 플랫폼을 통해 100k Sales를 발생시키고, 플랫폼이 그에게 1m Working Capital을 제공합니다.

상환은 반드시 Merchant가 매달主动 Wire Transfer를 해야 하는 것은 아닙니다.

그것은 완전히 미래의:

Settlement → Deduction → Repayment에서 발생할 수 있습니다.

Stripe Capital은 매우 전형적인 구조입니다. Stripe는 Processing Volume과 Payment History 등의 요소를 결합하여 Financing Offer를 형성하며, 상환은 미래 Stripe Sales에서 비율에 따라 직접 완료될 수 있습니다; 동시에, Stripe의 Merchant Relationship, Payment Flow 및 최종적으로 Balance Sheet를 제공하는 주체는 반드시 동일한 회사일 필요는 없습니다.

이러한 모델은 특히 참고할 가치가 있습니다.

왜냐하면 이는 Credit Product를 보유하는 것이 반드시 최종 Balance Sheet를 보유해야 한다는 것을 의미하지 않기 때문입니다.

Payment Platform은 다음을 책임질 수 있습니다:

Flow + Data + Distribution.

은행 또는 기타 Capital Provider는 다음을 책임질 수 있습니다:

Funding + Risk Capital.

이것은 Payment Company와 전통적인 대출자 간의 가장 큰 구조적 차이점 중 하나입니다:

Payment Company는 Cash Flow를 볼 수 있을 뿐만 아니라, 많은 경우 Cash Flow를 통제하기도 합니다.

Flow는 한쪽에서 Underwriting을 해결하고, 다른 쪽에서는 직접 Repayment Rail이 됩니다. 그래서:

Underwriting → Disbursement → Repayment

모두 Flow에 내장됩니다.

이 관점에서 보면, Payment Company가 Credit에 진입하는 것은 단순한 Product Expansion이 아닙니다.

그 뒤에는 매우 강력한 Infrastructure Logic이 있습니다:

Flow 자체가 Data이자, Repayment Rail입니다.

칠, Credit은 결국 Balance Sheet로 돌아간다

만약 Payment Platform이 이미 Flow, Data, Customer Relationship를 보유하고 있다면, 왜 모든 것을 스스로 Credit로 처리하지 않을까요?

Data와 Balance Sheet는 완전히 다른 능력입니다.

Payment Platform이 더 잘하는 것은:

Flow / Data / Distribution / Customer Relationship / Repayment Control.

은행과 Institutional Capital은 더 잘하는 것은:

Funding / Credit Capacity / Risk Capital / Balance Sheet.

양측이 보유한 자원은 다릅니다.

그래서 미래의 Payment + Credit에서 가장 주목할 만한 것은, 반드시 더 많은 PSP가 스스로 은행이 되는 것이 아닙니다.

오히려 Credit Stack이 점점 더 명확하게 분리될 가능성이 높습니다:

• Payment Platform: Flow + Distribution

• Credit Infrastructure: Underwriting + Orchestration

• Bank / Private Capital: Balance Sheet

Stripe Capital에서 이러한 구조를 볼 수 있습니다: Credit Product는 Payment Experience에 내장될 수 있지만, 최종 Financing Provider는 반드시 Payment Platform 자신일 필요는 없습니다.

Huma/Arf, MANSA는 유사한 분리를 Payment Settlement 자체로 더 가져가려는 시도를 하고 있습니다.

과거에는 Bank Credit Line과 Payment System이 종종 두 개의 상대적으로 독립적인 Infrastructure였습니다.

미래에는 Credit Capacity 자체가 Payment Flow에 더 직접적으로 연결되어, 정산이 실제로 발생할 때 동적으로 호출될 수 있습니다.

그래서 미래에 진정으로 물어봐야 할 것은, "어느 PSP가 대출을 시작했는가?"가 아니라: 누가 Flow를 통제하는가? 누가 Credit를 결정하는가? 누가 최종적으로 Balance Sheet를 제공하는가?

이 세 가지는 점점 더 동일한 회사에서 발생할 필요가 없습니다.

Payment Company는 Flow를 보유하고 있습니다.

은행과 Capital Market은 Balance Sheet를 보유하고 있습니다.

그리고 Credit은:

Flow와 Balance Sheet를 연결하는 그 층입니다.

결론: Credit은 Payment의 부가적인 것이 아니라, 시간의 가격이다

글의 시작 부분의 질문으로 돌아가 보겠습니다:

돈이 아직 도착하지 않았는데, 왜 이미 지불할 수 있습니까?

규모가 작을 때는 대답이 매우 간단할 수 있습니다. PSP가 먼저 선불하는 것이며, 이는 우선 Self-funded Prefunding입니다.

규모가 조금 더 커지면, Treasury가 자신의 글로벌 Balance Sheet에서 Position을 조정할 수 있습니다.

하지만 Payment Obligation이 점점 더 실시간으로 이루어지고, Volume이 점점 더 커지며, Own free Cash가 무한히 확장될 수 없을 때, External Funding을 찾기 시작해야 합니다.

그래서 Payment, Liquidity, Funding 및 Credit은 사실 하나씩 내려가는 것입니다.

Payment는 해결합니다:

Money Movement.

Liquidity는 해결합니다:

기존 Money가 올바른 시간에 올바른 위치에 나타나는 방법.

Funding은 해결합니다:

현재 Position이 부족할 때, Gap을 어디서 메울 것인가.

그리고 Credit은 더 나아가 해결합니다:

미래의 상환 능력을 기반으로, 추가 Financial Capacity를 오늘로 가져오는 방법.

이 상환 능력은 미래 Cash Flow, Receivables, Collateral에서 올 수 있으며, 기관 자체의 Credit Profile에서 올 수 있습니다.

그래서:

Liquidity는 Position을 관리합니다.

Credit은 Elasticity를 제공합니다.

한 층 더 내려가면, 전체 Network가 얼마나 커질 수 있는지를 결정하는 것은 여전히:

Balance Sheet입니다.

이것이 Payment Industry가 결국 Credit에 점점 더 가까워지는 이유입니다.

모든 PSP가 결국 Lender가 되고 싶어서가 아닙니다.

오히려 Payment가 실시간으로 이루어지고, Volume이 커지며, Settlement Chain이 복잡해질수록, 누군가가 매우 현실적인 질문에 대답해야 할 필요가 커집니다:

오늘의 돈이 아직 도착하지 않았지만, Payment는 멈출 수 없다면, 어떻게 해야 합니까?

자신의 Balance Sheet가 충분하다면, 스스로 부담합니다.

부족하다면, 반드시 다른 사람의 Balance Sheet를 호출해야 합니다.

물론, 이른바 "Credit은 시간의 가격이다"라는 것은 Credit이 단지 시간에 대한 요금을 부과한다는 것을 의미하지 않습니다. 실제로 가격이 책정되는 것은 이 Timing Gap 뒤에 있는 Credit Risk, Liquidity Cost, Capital Consumption, 그리고 자금 제공자가 이 불확실성을 감수하려는 가격입니다.

그래서 Credit은 결코 단순한 Loan Product가 아닙니다. 오히려 Payment Network가 Time, Peak Volume 및 Settlement Mismatch에 직면했을 때, 동적으로 확장할 수 있는 Financial Capacity의 한 층입니다.

이런 의미에서:

• Customer Funds는 당신이 관리하는 돈의 양을 결정합니다.

• Own free Cash는 당신이 선불로 사용할 수 있는 돈의 양을 결정합니다.

• Credit Capacity는 Own Cash가 부족할 때, 당신이 계속 약속할 수 있는 돈의 양을 결정합니다.

그리고 Payment Industry의 가장 기본적인 사실은 여전히 변하지 않았습니다:

Payment Volume은 PSP 자신의 Balance Sheet보다 훨씬 클 수 있지만, Cash Arrival과 Payment Obligation이 동기화되지 않을 때, 이 Gap은 결국 어느 한 Balance Sheet이 부담해야 합니다.

Payment는 Money를 이동시키고, Liquidity는 Money를 조정하며, Credit은 미래의 Financial Capacity가 오늘의 Payment를 지원할 수 있도록 합니다.

결국, 하나의 Balance Sheet가 결정하는 것은 당신이 역사적으로 얼마나 많은 거래를 처리했는지가 아닙니다.

오히려 돈이 아직 진정으로 도착하지 않았을 때------

당신이 과연 얼마나 더 약속할 수 있는가입니다.