Siemens가 5년에 걸쳐 만들어 온 Real-time Treasury

글로벌 기업의 재무담당자에게 가장 중요한 질문 중 하나는 단순합니다.

“내일 어디에 얼마의 돈이 필요할까?”

국가가 많아질수록 이 질문은 어려워집니다.

미국 법인의 급여일이 다가오고,
아시아에서는 공급업체 지급이 발생하고,
유럽에서는 대규모 투자대금이 빠져나갑니다.

통화도 다르고, 은행도 다르고, 영업시간도 다릅니다.

그래서 기업 Treasury는 미래의 자금수요를 예측합니다.

그리고 예측이 틀릴 가능성에 대비해 각 계좌에 일정한 현금을 남겨둡니다.

결국 기업이 보유한 현금 중 일부는
지금 필요해서가 아니라, 혹시 필요할지 모르기 때문에 존재합니다.

Siemens는 이 오래된 Treasury의 운영방식에 다른 질문을 던졌습니다.

현금을 더 정확히 예측하는 대신,
실제로 필요해지는 순간 돈이 자동으로 움직이게 할 수는 없을까?

이 질문에서 Siemens의 Real-time Treasury 실험이 시작됐습니다.

2,000개의 계좌를 관리하는 문제

Siemens 같은 글로벌 기업의 Treasury를 이해하려면 먼저 규모를 봐야 합니다.

Siemens는 전 세계에 약 2,000개의 은행계좌를 보유하고 있었고,
여러 지역과 시간대에 흩어진 자금을 관리해야 했습니다.

Siemens Group Treasurer Peter Rathgeb는 이 구조를 두고
“돈이 항상 필요한 곳에 있는 것은 아니다”라고 설명합니다.

문제는 단순히 계좌가 많다는 것이 아닙니다.

계좌가 많아지면,

• 잔액을 확인해야 하고
• 필요한 자금을 미리 배치해야 하고
• 부족하면 다시 이동시켜야 하고
• 내부거래를 맞춰야 하며
• 은행 수수료와 계좌관리 업무도 증가합니다.

특히 주말이나 야간처럼 Treasury 직원이 실시간으로 대응하기 어려운 시간에는
더 많은 Liquidity Buffer(유동성 완충자금)가 필요합니다.

J.P. Morgan은 Siemens가 기존 구조에서 경험한 문제를
복잡한 Cash Pool, 다수의 분산된 계좌, 수작업 Cash Allocation,
그리고 24시간 비즈니스에 맞지 않는 운영방식으로 설명합니다.

Siemens의 고민은 결국 아래 질문으로 귀결됩니다.

'기업은 24시간 움직이는데,
Treasury는 왜 여전히 영업시간과 사람의 판단에 맞춰 움직여야 하는가?'

예측에서 이벤트로

2021년 Siemens와 J.P. Morgan은 Programmable Payments를 테스트했습니다.

구조는 의외로 단순합니다.

기존 방식에서는 담당자가 계좌잔액을 확인하고, 부족한 금액을 계산하고, 지급을 승인해야 합니다.

Programmable Payment에서는 사전에 Rule을 정합니다.

예를 들어, 아래처럼 설정할 수 있습니다.

“특정 법인의 계좌잔액이 일정 금액 아래로 내려가면
중앙 Treasury 계좌에서 자동으로 자금을 공급한다.”

그러면 사람이 잔액을 발견하고 대응하는 대신,

Real-time Data → Rule 충족 → Payment 실행

이 자동으로 이어집니다.

J.P. Morgan은 이를 두고 Treasury가
Static(정적인) 조직에서 Responsive, Real-time Treasury로 이동한다고
설명했습니다.

Siemens의 Heiko Nix도
이 기술이 Real-time Treasury를 만드는 기반이라고 설명합니다.

그에게 중요한 문제는 단순히 송금속도가 아니었습니다.

Pay-per-use, Subscription 같은 새로운 비즈니스 모델에서는
과거보다 훨씬 많은 수의 거래가, 훨씬 작은 금액으로 발생합니다.

기존처럼 사람이 개별 거래와 자금배치를 관리하는 방식으로는 확장하기 어렵습니다.

여기서 Siemens가 바꾸려 한 것은 결제방식보다
Treasury의 의사결정 방식입니다.

기존에는 미래를 예측한 뒤 돈을 움직였습니다.

이제는 실제 이벤트가 발생하면 돈이 반응합니다.

Forecast-based Treasury → Event-driven Treasury

저는 이것이 Siemens 사례에서 가장 중요한 변화라고 생각합니다.

왜 Cash Forecasting만 더 정교하게 만들지 않았을까

기업 Treasury 입장에서 이 질문은 중요합니다.

AI와 데이터 분석을 이용하면 Forecast를 더 정확하게 만들 수도 있습니다.

그런데 Forecast는 아무리 정교해져도 결국 미래에 대한 추정입니다.

예상치 못한 고객 입금, 공급업체 지급, 대규모 투자, 환율 변화가 발생하면 오차가 생깁니다.

그리고 오차가 존재하는 한 기업은 안전을 위해 Buffer를 유지해야 합니다.

Siemens의 접근은 Forecast를 없애자는 것이 아닙니다.

오히려 Forecast가 틀려도 운영에 문제가 생기지 않는 구조를 만드는 것에 가깝습니다.

Heiko Nix는 Programmable Payments가 Trigger Event에 따라 특정 계좌를 자동으로 다시 채울 수 있기 때문에, 계좌마다 Cash Buffer를 쌓아두거나 사람이 밤낮으로 모니터링할 필요를 줄일 수 있다고 설명합니다.

이 차이는 작아 보이지만 Treasury의 사고방식을 바꿉니다.

더 잘 예측하는 Treasury에서
예측이 틀려도 대응할 수 있는 Treasury로 이동하는 것입니다.

Money + Rules + Data

Programmable Money라는 표현을 들으면
돈 자체에 복잡한 프로그램을 넣는 모습을 떠올리기 쉽습니다.

하지만 Siemens 사례를 보면 본질은 조금 다릅니다.

필요한 것은 세 가지입니다.

Money
24시간 이동할 수 있는 자금

Rules
언제, 얼마를, 어디로 이동할 것인지 정하는 조건

Data
계좌잔액, 지급정보, 시장정보처럼 Rule을 작동시키는 실시간 정보

세 가지가 연결되면 지급은 더 이상 독립적인 행위가 아닙니다.

기업의 실제 비즈니스 상황이 곧 금융거래를 작동시키는 Trigger가 됩니다.

Programmable Money의 진짜 변화는 돈에 코드를 넣는 것이 아니라,
돈의 이동을 결정하는 Data와 Rule을 거래와 직접 연결하는 데 있습니다.

첫 실제 거래는 €100 million이었다

여기까지는 많은 기업의 PoC와 비슷해 보입니다.

하지만 Siemens는 기술검증을 실제 운영으로 넘겼습니다.

초기 테스트 이후 첫 Programmable Payment는
€100 million 규모의 내부 자금이동이었습니다.

그리고 이 거래가 정상적으로 수행된 후 외부 Programmable Payment로 확대했습니다.

왜 이 숫자가 중요할까요.

€100를 성공적으로 보내는 것과
€100 million을 기업 Treasury가 맡기는 것은 전혀 다른 문제이기 때문입니다.

기업 재무에서 새로운 기술은 단순히 ‘작동한다’는 것만으로 충분하지 않습니다.

다음 질문을 통과해야 합니다.

• 회계처리가 가능한가
• 내부통제가 유지되는가
• 감사할 수 있는가
• 오류가 발생하면 대응할 수 있는가
• 법적 책임은 명확한가
• 기존 ERP와 Treasury System에 연결되는가

Siemens가 원한 것은 Crypto Treasury가 아니었습니다.

Heiko Nix는 이를 상당히 명확하게 표현했습니다.

Siemens는 Crypto World가 제공하는 Programmability와 24/7의 장점은 원하지만, 그 단점까지 가져오고 싶지는 않다고 설명합니다.

이 지점은 최근 은행들의 Digital Asset 접근과도 닮아 있습니다.

새로운 금융 인프라는 기존 금융의 통제를 버리는 방향보다,
기존 금융의 책임과 통제 위에 새로운 기능을 추가하는 방식으로 발전하고 있습니다.

그런데 Blockchain만으로는 부족했다

Siemens 사례를 “Blockchain Treasury”라고 부르면 절반만 설명하게 됩니다.

실제 Siemens가 만든 구조에는 여러 요소가 함께 들어갑니다.

계좌 통합 · 중앙 자금관리
        +
Virtual Accounts
        +
API / Real-time Data
        +
Blockchain-based Accounts
        +
Programmable Payments

J.P. Morgan과 Siemens는 미국에서 100개 이상의 실물계좌를
하나의 Physical Account 아래 Virtual Account 구조로 통합했습니다.

또 미국·독일·싱가포르에 Blockchain-based Account를 만들어
EUR와 USD를 중심으로 24/7 자금이동이 가능한 Corridor를 구축했습니다.

Programmable Payments는 그 위에서 Cash Allocation, Intercompany Funding, Liquidity Concentration을 자동화합니다.

즉 핵심은 Blockchain을 하나 더 붙인 것이 아닙니다.

Treasury Architecture 자체를 단순화한 것입니다.

이 순서가 중요합니다.

Siemens는 복잡한 Treasury 구조를 그대로 두고
Blockchain부터 도입하지 않았습니다.

먼저 계좌를 줄이고,
Cash Management를 중앙화하고,
Virtual Account를 도입하고,
API로 실시간 데이터를 연결한 뒤,

그 위에 24/7과 Programmability를 추가했습니다.

성과는 Blockchain 하나의 성과가 아니었다

Siemens의 전체 Treasury Transformation 결과도 공개돼 있습니다.

J.P. Morgan에 따르면 Siemens는 아래의 효과를 거둔 것으로 소개됩니다.

• Bank Account와 Cash Pool을 50% 이상 축소
• 내부 관리업무를 70% 감소
• Virtual Account 기반 Cash Application을 80% 자동화
• 2024년 Bank Fee를 50% 절감
• 전체적으로 연간 $20 million 이상 절감

다만 이 숫자를 Blockchain의 ROI라고 해석하는 것은 주의가 필요합니다.

이 성과는 Virtual Account, Account Rationalisation, API, POBO/COBO, Programmable Payments, 조직과 프로세스 개선이 함께 만들어낸 결과입니다.

오히려 이것이 Siemens 사례를 더 흥미롭게 만듭니다.

기업의 Digital Asset Transformation은 Blockchain 프로젝트로 성공하는 것이 아니라, 기존 금융 프로세스의 재설계 속에 Blockchain이 들어갈 때 성과가 만들어진다는 것입니다.

자산만 디지털화하면 무엇이 남을까

Siemens의 Digital Bond 사례에서도 같은 패턴이 반복됩니다.

2023년 Siemens는 독일 전자증권법에 따라
€60 million 규모의 Digital Bond를 Public Blockchain에서 발행했습니다.

증권은 Blockchain에서 발행됐습니다.

하지만 대금지급은 여전히 기존 은행계좌를 이용했습니다.

거래 완료에는 약 이틀이 걸렸습니다.

구조로 표현하면 간단합니다.

Digital Asset
     ↓
Traditional Money

Asset Leg는 디지털화됐지만
Money Leg는 기존 방식에 남아 있었습니다.

이듬해 Siemens는 같은 문제를 다시 풀었습니다.

2024년 €300 million Digital Bond에서는 SWIAT의 Permissioned Blockchain과 Deutsche Bundesbank의 Trigger Solution을 이용해 증권과 중앙은행 화폐를 동기화했습니다.

결제는 이틀에서 수분으로 단축됐고,
Siemens는 Settlement Risk가 거의 제거됐다고 설명했습니다.

여기서 또 하나의 중요한 원칙이 드러납니다.

자산을 Tokenize했다고 금융거래가 실시간으로 바뀌는 것은 아닙니다.
Money Leg가 함께 움직여야 합니다.

그리고 마지막에는 FX가 필요해진다

글로벌 기업에게 또 하나의 문제가 남습니다.

현금을 24시간 움직일 수 있어도
국가가 다르면 통화가 다릅니다.

결국 FX가 필요합니다.

Siemens는 이후 Kinexys를 통해
USD와 EUR를 연결하는 On-chain FX 기능까지 확대했습니다.

J.P. Morgan이 공개한 Siemens Treasury 사례에서도 Blockchain-based Account와 Cross-border FX를 결합해 아시아·유럽·미주 간 기존 Cash를 24시간 활용하는 구조가 소개됩니다.

여기서 Siemens가 지향하는 모습이 보다 명확해집니다.

Cash
  ↓
Programmability
  ↓
24/7 Liquidity
  ↓
FX
  ↓
DvP / Tokenised Asset

처음에는 계좌잔액을 자동으로 채우는 문제였습니다.

그 문제를 해결하고 나니
통화가 달라지고,

통화를 해결하고 나니
자산결제가 연결됩니다.

Siemens가 바꾼 것은 결제가 아니라
‘시간’일 수 있다

Siemens 사례를 여러 프로젝트로 나눠 보면 복잡합니다.

Programmable Payment도 있고,
Blockchain Account도 있고,
Virtual Account도 있고,
Digital Bond와 FX도 있습니다.

하지만 하나의 흐름으로 보면 꽤 단순합니다.

Siemens가 바꾸고 있는 것은 기업이 돈을 관리하는 시간의 구조입니다.

기존 Treasury는 미래를 미리 준비해야 했습니다.

예측
↓
현금 배치
↓
Buffer 확보
↓
모니터링
↓
조정

Real-time Treasury에서는 순서가 달라집니다.

실제 Event 발생
↓
Data 확인
↓
Rule 작동
↓
자금 이동
↓
즉시 Settlement

Forecast → Event

Pre-positioned Liquidity → On-demand Liquidity

이 변화가 충분히 진행된다면
Real-time Treasury의 의미는 단순히 송금이 빨라지는 데 있지 않습니다.

기업이 돈을 미리 쌓아둘 이유 자체가 줄어드는 것에 더 가깝습니다.

이것은 Working Capital의 문제이기도 하다

기업에게 Cash Buffer는 안전장치입니다.

하지만 동시에 다른 곳에서 사용할 수 없는 자금입니다.

여러 국가와 계좌에 여유자금이 분산되어 있으면
그만큼 Working Capital의 효율성은 낮아집니다.

따라서 Real-time Treasury의 경제적 가치는 단순한 Payment Fee 절감보다 더 넓게 봐야 합니다.

• Idle Cash 감소
• Pre-funding 감소
• Liquidity Buffer 감소
• Working Capital 활용도 향상
• Intraday Liquidity 최적화
• Treasury 인력의 반복업무 감소

Siemens 사례에서 이미 확인되는 계좌 축소와 자동화, 수수료 절감은 이런 방향성을 보여줍니다. 다만 공개자료만으로 Programmable Payments 자체가 각각 얼마의 Working Capital을 절감했는지까지 분리해서 확인할 수는 없습니다.

그럼에도 기업 재무담당자라면 질문은 자연스럽게 이어집니다.

“실시간으로 자금을 움직일 수 있다면,
지금 우리가 안전을 위해 미리 쌓아두고 있는 현금 중 얼마가 정말 필요한가?”

어쩌면 이 질문이 Blockchain의 TPS보다 기업에게 훨씬 중요한 질문일 수 있습니다.

금융회사 입장에서는 무엇이 달라질까

여기서부터는 Siemens 사례를 바탕으로 한 제 해석입니다.

기업 Treasury가 Event-driven 방식으로 바뀐다면
은행이 제공해야 할 서비스도 달라집니다.

과거 은행의 역할은 주로 아래 요소를 각각 제공하는 것이었습니다.

• Account
• Payment
• FX
• Credit

하지만 Real-time Treasury에서는 이 기능들이 하나의 Transaction 안에서 연결돼야 합니다.

예를 들어,

기업 자금 부족 감지
        ↓
Liquidity Rule 확인
        ↓
필요 통화 확인
        ↓
FX 실행
        ↓
자금 이동
        ↓
Settlement

이 일련의 과정을 기업이 하나의 서비스처럼 사용할 수 있어야 합니다.

그렇다면 미래 Transaction Banking의 경쟁력은 단순히 좋은 계좌를 제공하는 데서 끝나지 않을 수 있습니다.

Data를 읽고
Liquidity를 판단하고
FX를 실행하고
Settlement까지 연결하는 능력

이 중요해집니다.

Wallet의 의미도 조금 달라질 수 있다

이 관점에서 보면 기업용 Digital Wallet 역시
단순히 디지털자산을 보관하는 도구로만 보기 어렵습니다.

Wallet이

• 기업의 Tokenised Money를 보유하고
• Bank Account와 연결되고
• FX를 실행하며
• 지급조건을 관리하고
• Tokenised Asset Settlement를 수행한다면,

Wallet은 하나의 Treasury Execution Layer가 될 수도 있습니다.

기업 고객에게 중요한 것은 ‘지갑’이라는 화면이 아닙니다.

Cash, FX, Asset, Liquidity를 실시간으로 연결할 수 있는 거래 실행 인프라입니다.

Siemens 사례는 그래서 금융회사에도 의미가 있습니다.

기업에게 Blockchain Wallet을 팔아야 한다는 이야기가 아닙니다.

기업이 원하는 Real-time Treasury를 만들기 위해
금융회사가 어떤 Execution Infrastructure를 제공할 수 있는가의 문제입니다.

다음 변화는 Cash만의 이야기가 아닐 수 있다

Siemens의 흐름은 이미 Digital Bond까지 연결되고 있습니다.

앞으로 이 구조에 Tokenised Securities와 Collateral이 더 들어오면,

Cash
  ↕
FX
  ↕
Securities
  ↕
Collateral

이 하나의 프로그래머블한 흐름으로 연결될 가능성이 있습니다.

그때 Tokenisation의 핵심 질문은 달라집니다.

“무엇을 Tokenize할 것인가?”

보다,

“Tokenized Asset을 금융시장에서 무엇에 사용할 것인가?”

가 중요해집니다.

Settlement, FX, Collateral, Liquidity가 연결되기 시작하면
Tokenisation은 단순한 자산의 디지털 표현을 넘어 금융시장 운영방식의 변화가 됩니다.

작은 문제에서 시작한 큰 변화

Siemens 사례에서 가장 흥미로운 부분은
회사가 처음부터 거대한 ‘Future of Finance’를 만들려고 했던 것이 아니라는 점입니다.

출발점은 매우 현실적인 문제였습니다.

계좌가 너무 많았습니다.

사람이 너무 많은 잔액을 확인해야 했습니다.

주말에도 돈은 움직여야 했습니다.

현금을 미리 배치해야 했습니다.

그리고 하나씩 해결했습니다.

계좌를 줄이고,
Virtual Account를 만들고,
API로 데이터를 연결하고,
Programmable Payment를 도입하고,
24/7 Money를 만들고,
FX와 Digital Asset Settlement까지 확장했습니다.

그래서 Siemens 사례에서 제가 가장 중요하게 보는 교훈은 이것입니다.

새로운 금융 인프라는 기술에서 Use Case를 찾는 방식보다,
기존 금융의 마찰에서 출발해 필요한 기술을 하나씩 연결하는 방식으로 만들어질 가능성이 높습니다.

그리고 Real-time Treasury의 본질도
돈을 몇 초 빨리 보내는 데 있지 않을 수 있습니다.

미래의 현금을 예측하고 미리 배치해야 했던 기업을,
실제 상황에 따라 돈이 움직이는 기업으로 바꾸는 것.

Siemens가 지난 몇 년 동안 실험해 온 것은
어쩌면 바로 이 변화에 대한 대응일 수도 있습니다.

by Louis Kim, with Ari

참고한 자료

1. J.P. Morgan, Programmable payments: automation becomes reality, 21 Dec. 2021.
   Siemens와 J.P. Morgan의 Programmable Payments PoC, Real-time Treasury 및 Event-driven Payments의 초기 문제의식.
   https://www.jpmorgan.com/insights/payments/blockchain-digital-assets/programmable-payments-automation-becomes-reality
2. Treasury Management International, Programmed for Success, 10 Apr. 2024.
   Siemens Head of Cash Management and Payments Heiko Nix 인터뷰. Cash Buffer, Programmability, €100m 초기 실거래, API 통합 및 24/7 Treasury 관련 상세 설명.
   https://treasury-management.com/articles/programmed-for-success
3. J.P. Morgan, How Siemens Treasury redefines financial operations through innovation and technology.
   Siemens의 약 2,000개 계좌 구조, Virtual Account, Blockchain-based Account, Programmable Payments, POBO/COBO 및 전체 Treasury Transformation의 성과.
   https://www.jpmorgan.com/insights/payments/blockchain-digital-assets/siemens-treasury-transformation
4. Siemens AG, Siemens issues first digital bond on blockchain, 14 Feb. 2023.
   €60m Public Blockchain Digital Bond. 증권은 온체인으로 발행했으나 대금은 기존 은행계좌로 지급했으며 거래 완료까지 약 이틀 소요.
   https://press.siemens.com/global/en/pressrelease/siemens-issues-first-digital-bond-blockchain
5. Siemens AG, Siemens remains a pioneer – Another digital bond successfully issued on blockchain, 2024.
   €300m Digital Bond, SWIAT와 Bundesbank Trigger Solution을 이용한 중앙은행 화폐 결제 및 수분 단위 자동 Settlement.
   https://press.siemens.com/global/en/pressrelease/siemens-remains-pioneer-another-digital-bond-successfully-issued-blockchain
6. J.P. Morgan, Blockchain Deposit Accounts, Kinexys by J.P. Morgan.
   Blockchain Deposit Account의 구조와 기존 Demand Deposit Account와의 관계, Near-real-time Settlement 및 Programmability.
   https://www.jpmorgan.com/kinexys/blockchain-deposit-accounts