*Last updated 3 November 2026 (Taipei time, UTC+8). Event times below are in UTC. Details of the incident are still emerging, and figures may change as investigations continue.*

Most companies that use stablecoins for payments or treasury are unlikely to run hot wallets on the scale of a global exchange. The Binance hack is still relevant to them, because it highlighted three risks that apply to ordinary businesses as well: funds held with a third party can become unavailable at short notice, stolen funds can reach a company's wallet through payments that look normal, and a signing process can be misused even when, as Binance has said so far, there is no evidence that private keys were leaked.

## Key takeaways

- Funds held with a third party can become unavailable at short notice. Binance suspended withdrawals for roughly two and a half days, so companies that kept operating stablecoins on the exchange could not pay or move funds during that time.
- Stolen funds can reach ordinary businesses through payments that look normal, so incoming stablecoin payments should be screened before they are credited and rechecked as new addresses are flagged.
- A signing process can be misused without stolen keys. Binance said it found no evidence that wallet private keys were leaked, which makes access to signing systems and approval controls as important as key protection.
- Each of these risks can be reduced through decisions a company already controls: where operating funds are held, when an incoming payment is treated as usable, and who can approve and sign.

## What happened

At around 20:05 UTC on 29 October 2026, funds began leaving Binance hot wallets across multiple blockchains. In its [Security Incident Update #2](https://www.binance.com/en/support/announcement/detail/d3306d9dca5243548c813b605e1d1751), Binance estimated the stolen amount at about USD 6.3 billion. Blockchain analytics firm [Elliptic put the outflow at USD 6.43 billion](https://www.elliptic.co/insights/binance-largest-hack-in-history/), the largest theft on record.

In the same update, Binance said that at this stage it had found no evidence that wallet private keys were leaked, and that its investigation had expanded beyond the initially suspected compromised engineer's laptop to additional points of breach. The FBI [attributed the theft to North Korea's TraderTraitor group](https://www.fbi.gov/investigate/cyber/alerts/2026/north-korea-responsible-for-6-billion-binance-attack) on 31 October.

Four different figures are easy to confuse, so it helps to keep them apart:

- **Stolen (outflow):** about USD 6.3 billion according to Binance, and USD 6.43 billion according to Elliptic.
- **Frozen onchain:** about USD 3 billion according to Binance as of 30 October, mostly stablecoins frozen by their issuers. Frozen funds can no longer be moved by the attacker, but they have not necessarily been returned.
- **Recovered:** no recovered amount had been reported as of early November. Binance's 30 October update said further recovery efforts would follow.
- **Covered by Binance:** Binance committed to covering the stolen assets from its SAFU fund and corporate treasury, and reported setting aside more than USD 6.34 billion for that purpose. By 1 November, it said about 95% of the impacted amount had been replenished with company funds, according to [Bitcoin Magazine](https://bitcoinmagazine.com/news/binance-reopens-withdrawals-hack).

## Risk one: operating funds held with a third party

The first effect for businesses was access. According to [onchain and press timelines compiled by Bitquery](https://bitquery.io/investigations/binance-hack), Binance paused withdrawals at about 22:30 UTC on 29 October. A phased reopening, starting with a limited set of tokens and networks, began on 1 November, and Binance said further phases would follow. A company that kept operating stablecoins on the exchange could not pay suppliers, process payouts, or move liquidity during that time, regardless of whether its own balance was ever at risk.

Binance committed to covering the stolen assets, but that commitment did not remove the disruption caused by suspended withdrawals. It was also a decision by one well-capitalized company, and businesses should not assume every provider would be able to make the same commitment.

The practical question is how much of the company's working balance sits with any single exchange, custodian, or payment provider, and how the company would keep operating if that balance were unavailable for a week. Many businesses use exchanges to convert between stablecoins and fiat. Keeping there only what each conversion requires, and holding operating funds in wallets the company controls under its own governance, limits the impact when a provider has to stop withdrawals.

## Risk two: stolen funds reaching your wallet

After a theft of this size, stolen assets move through swaps, bridges, and new addresses, and some may eventually reach businesses that had nothing to do with the attack. Bitquery's analysis shows the attacker converting stablecoins into ETH and TRX through decentralized exchanges and moving funds across several bridges within hours.

Alongside its attribution, the FBI asked private-sector firms to block transactions with addresses linked to the laundering. [CoinDesk reported](https://www.coindesk.com/policy/2026/10/31/fbi-confirms-north-korea-s-role-in-usd6-billion-binance-hack-asks-defi-community-to-block-btc-eth-sol-addresses) that the list included more than 600 Ethereum addresses, about 20 Bitcoin addresses, and one Solana address. Lists like these tend to grow as investigators trace funds, and attribution can change in the days after an incident.

A business cannot stop a third party from sending funds to one of its public addresses. What it can control is what happens next. Incoming payments should be screened before the business credits the customer, releases goods or services, or makes the funds available for use. Payments accepted before an address was flagged may also need to be rechecked. Giving each customer or invoice its own receiving address also helps. When every payment arrives at an address linked to a known payer, it is easier to tell who sent what, and to trace and resolve a payment if its source is later flagged. A receipt that later turns out to be linked to stolen funds can create compliance, accounting, and relationship problems, even when the business acted in good faith.

Stablecoins add one more consideration. Tether and Circle froze large amounts of USDT and USDC held by the attacker, in some cases within minutes, and Elliptic counts about USD 2.85 billion frozen or seized across issuers and networks. Native assets such as bitcoin and ether have no issuer able to freeze them. Freezing limited what the attacker could move, though it did not by itself mean those assets were recovered or returned. The same issuer powers apply to every holder, so a company's own stablecoin balance is subject to the issuer's policies, which is another reason to know where incoming funds come from and to keep records showing the company's addresses are used for legitimate business.

*KryptoGO analysis:* for businesses that receive stablecoin payments, this incident highlights why risk screening should continue after a payment is received, as new address intelligence becomes available.

## Risk three: your own signing process

The third risk sits inside the company. Binance said it had found no evidence that wallet private keys were leaked, while its investigation pointed to unauthorized withdrawal transactions submitted through internal systems. If that holds, the attacker reached systems that could ask for signatures rather than the keys themselves.

In a smaller company, the equivalent might be a single employee's account that can both create and approve a transfer, a payment tool that signs whatever the finance system sends it, or a wallet whose approval screen shows a summary rather than the actual transaction. None of these requires a stolen key to cause a loss.

The relevant controls are the ones covered in our guide to [Maker, Approver, and Signer roles](https://www.kryptogo.com/blog/maker-approver-signer-enterprise-wallet): approvals tied to the exact transaction being signed, independent approvers for larger payments, limits on how much can leave in a day, and a quick way to pause signing.

On Ethereum, published analysis by [Fireblocks](https://www.fireblocks.com/blog/binance-hack-eip-7702) and Bitquery indicates that the attacker used a signed EIP-7702 authorization to delegate a Binance hot wallet to malicious contract code. Fireblocks notes that this involved creating a new authorization, not exploiting an existing EIP-7702 contract. Under the [EIP-7702 specification](https://eips.ethereum.org/EIPS/eip-7702), such a delegation stays in place until the account changes or clears it. Companies using wallets on Ethereum and compatible networks should treat delegation changes and new contract interactions as high-risk actions, not only outgoing transfers.

## What should a business review now?

If your company holds, receives, or sends stablecoins, the incident is a useful prompt to check three things, one for each risk.

**Funds held with third parties.** List every exchange, custodian, and payment provider that holds company funds, and the balance with each. For each one, decide how the company would keep paying suppliers and staff if that balance were unavailable for a week.

**Incoming payments.** Check whether incoming stablecoin payments are screened before customers are credited or funds are used, and whether the risk data is updated as new addresses are flagged. Payments received since 29 October are worth rechecking against the latest lists.

**Your own signing process.** Find out which people, services, and devices can submit a transaction for signing, and whether any single account can both create and approve a payment. Confirm that approvers and signers see the actual transaction details, and that a change after approval sends the request back for review.

Finally, agree in advance who would contact issuers, exchanges, and analytics providers if the company's own funds were affected. In an incident, those calls need to happen within hours.

## What is still unknown

Binance has not published how the laptop was compromised, which credentials gave access to its internal systems, or what the additional points of breach were. Recovery figures are still changing, and laundering of the funds that were not frozen is ongoing. Conclusions drawn now should be treated as provisional.

## What this means for businesses

For companies that use stablecoins, the Binance hack is less a story about an exchange than a large-scale example of three risks they already carry: relying on a provider that can stop withdrawals, accepting funds without knowing where they came from, and running a signing process that trusts whatever reaches it. The first two do not require a company to be targeted at all. Each can be reduced through decisions the company already controls: where operating funds are held, when an incoming payment is treated as usable, and who can approve and sign.

## Where KryptoGO fits

Each of the three risks in this incident maps to something a company can put in place before the next one.

**Funds held with a third party.** Much of this is a treasury decision: keeping operating balances in wallets the company controls, and leaving on exchanges only what each conversion needs. KryptoGO's enterprise wallet infrastructure is built for that kind of company-held balance, with role-based permissions and approval workflows so that self-held funds do not end up controlled by a single person.

**Stolen funds in incoming payments.** KryptoGO's transaction monitoring screens the addresses a company receives from, so a payment can be checked before the customer is credited or the funds are used. KryptoGO can also generate a dedicated receiving address for each invoice, so every incoming payment is tied to a known payer and invoice from the start. For new business counterparties, KYB gives the company a verified record of who it is dealing with.

**Misuse of the signing process.** Approval workflows and address allowlists apply the controls described in our Maker, Approver, and Signer guide, and audit records show who requested, approved, and signed each transfer.

**Talk to KryptoGO about reviewing your third-party exposure, incoming payment screening, and approval controls.**

*This article is for general information only and does not constitute legal, security, or compliance advice. It reflects publicly available information as of 3 November 2026 (Taipei time).*

## Frequently asked questions

### Were businesses with funds on Binance affected?

Binance committed to covering the stolen assets. The main effect for businesses was the suspension of withdrawals, which lasted roughly two and a half days before a phased reopening for a limited set of tokens and networks began on 1 November.

### Could stolen funds from the Binance hack reach my company?

It is possible. Stolen funds are being swapped and moved across networks, and some may reach ordinary businesses through normal payments. Screening incoming payments and rechecking recent receipts helps a business identify and manage that risk, although it cannot stop third parties from sending funds to a public address.

### Were the frozen funds recovered?

Not necessarily. Freezing stops the attacker from moving the tokens, but recovery and return are separate steps. No recovered amount had been reported as of early November; the funds Binance used to cover losses came from its own reserves.

### Who was behind the Binance hack?

The FBI attributed the theft to North Korea's TraderTraitor group on 31 October 2026.

## Sources

- Binance, [*Security Incident Update #2*](https://www.binance.com/en/support/announcement/detail/d3306d9dca5243548c813b605e1d1751), 30 October 2026.
- Federal Bureau of Investigation, [*North Korea Responsible for $6 Billion+ Binance Attack*](https://www.fbi.gov/investigate/cyber/alerts/2026/north-korea-responsible-for-6-billion-binance-attack), 31 October 2026.
- CoinDesk, [*FBI confirms North Korea's role in $6 billion Binance hack*](https://www.coindesk.com/policy/2026/10/31/fbi-confirms-north-korea-s-role-in-usd6-billion-binance-hack-asks-defi-community-to-block-btc-eth-sol-addresses), 31 October 2026.
- Elliptic, [*The largest theft in history: North Korea likely behind the $6.4 billion Binance hack*](https://www.elliptic.co/insights/binance-largest-hack-in-history/), October 2026.
- Bitquery, [*Binance Hack: $6.3B Drained on 9 Chains*](https://bitquery.io/investigations/binance-hack), October 2026.
- Bitcoin Magazine, [*Binance Reopens Withdrawals As Hack Recovery Enters Second Week*](https://bitcoinmagazine.com/news/binance-reopens-withdrawals-hack), 2 November 2026.
- Fireblocks, [*Deconstructing the Binance Exploit*](https://www.fireblocks.com/blog/binance-hack-eip-7702), 30 October 2026.
- Ethereum Improvement Proposals, [*EIP-7702: Set Code for EOAs*](https://eips.ethereum.org/EIPS/eip-7702).

數位金融洪流與暗影駭客 KryptoGO Blog.png

The Binance hack exposed three risks for any business using stablecoins: frozen third-party balances, tainted incoming payments, and misused signing access.

*最後更新：2026 年 11 月 3 日（台北時間）。文中具體時刻以 UTC 標示，並附台北時間。事件仍在調查中，資訊可能還會變動。*

多數用穩定幣收付款或管理資金的企業，熱錢包規模都遠不及全球交易所。但幣安這次被盜，跟一般企業其實很有關係。它讓三個企業也會遇到的風險浮上檯面：放在第三方的錢可能突然領不出來；遭竊資金可能混在正常付款裡，流進企業的錢包；即使私鑰未外洩，簽署流程仍可能被濫用。

## 重點整理

- 放在第三方的錢，可能突然領不出來。對依賴幣安調度資金、又沒有備用資金來源的企業來說，暫停提領可能延誤供應商付款、薪資或其他營運支出。
- 遭竊資金可能混在正常付款裡流進企業。收到穩定幣款項後，應先完成篩查，再決定是否開放使用；之後有新的風險資訊出現，也要回頭再查。
- 即使私鑰未外洩，簽署流程仍可能被濫用。幣安表示目前沒有發現錢包私鑰外洩的證據，這說明企業除了保護私鑰，也要管好「能要求簽署的系統」。
- 凍結、追回、補足是三件不同的事。穩定幣發行商凍結了大量遭竊代幣，但凍結只是讓攻擊者動不了錢；幣安用來補損失的資金，來自公司自己的準備。

## 事件經過

2026 年 10 月 29 日約 20:05 UTC（台北時間 10 月 30 日 04:05），幣安多條區塊鏈上的熱錢包開始有資金流出。幣安在 [Security Incident Update #2](https://www.binance.com/en/support/announcement/detail/d3306d9dca5243548c813b605e1d1751) 估計遭竊約 63 億美元。[Elliptic 估計流出 64.3 億美元](https://www.elliptic.co/insights/binance-largest-hack-in-history/)，並評估這可能是已知規模最大的單一竊案。

幣安在同一份公告中表示，目前沒有發現錢包私鑰外洩的證據。調查一開始懷疑是一名工程師的筆電遭入侵，後來又發現其他入侵點。美國聯邦調查局（FBI）10 月 31 日[指出這起竊案是北韓駭客組織 TraderTraitor 所為](https://www.fbi.gov/investigate/cyber/alerts/2026/north-korea-responsible-for-6-billion-binance-attack)。

這起事件有四類數字很容易搞混。各來源的更新時間、涵蓋資產和統計口徑也不同，數字不宜直接比較，也不能相加。

- **被盜走的金額**：幣安估計約 63 億美元，Elliptic 估計 64.3 億美元。
- **鏈上凍結的金額**：幣安 10 月 30 日表示約 30 億美元，大多是穩定幣發行商凍結的；Elliptic 另外統計凍結或扣押約 28.5 億美元。凍結後攻擊者動不了這些錢，但不代表已經還回來。
- **追回的金額**：本文引用的公告，尚未列明已追回並返還的金額。
- **幣安自己補上的金額**：幣安表示將以 SAFU 基金和公司資金承擔損失，並已準備超過 63.4 億美元。據 [PYMNTS](https://www.pymnts.com/cryptocurrency/2026/binance-says-it-replaced-95-percent-of-stolen-crypto-for-users/) 報導，幣安在 11 月 1 日的更新中表示已補上約 95% 的受影響金額。

## 目前還不清楚的部分

幣安還沒公布筆電是怎麼被入侵的、攻擊者用了哪些憑證進入內部系統，以及其他入侵點是什麼。追回的數字還在變動。部分未凍結的資金已被兌換或跨鏈轉移，另有大量資產仍留在相關地址，後續動向仍待追蹤。現在得出的結論，都只能先當作暫時的判斷。

## 風險一：放在第三方的營運資金

企業最先遇到的問題，是錢領不出來。根據 [Bitquery 整理的鏈上與媒體時間線](https://bitquery.io/investigations/binance-hack)，幣安大約在 10 月 29 日 22:30 UTC（台北時間 10 月 30 日 06:30）暫停提領。Elliptic 記錄，提領約在 11 月 1 日 06:00 UTC（台北時間 14:00）開始恢復，先從比特幣網路開始，其他幣種和網路再分階段開放。從暫停到開始部分恢復，大約兩天半。

對依賴這家交易所調度資金、又沒有備用資金來源的企業來說，這段期間可能延誤供應商付款、薪資或其他營運支出，就算自己的餘額根本沒有被盜，也一樣受影響。幣安表示將以 SAFU 基金和公司資金承擔損失，但暫停提領造成的營運中斷還是發生了，企業也不應假設每家服務商都能做出同樣的承諾。

比較實際的做法，是依照付款需求、兌換頻率和公司自己的管理能力，為每家服務商設定資金上限，並保留備用的付款管道。把資金放在公司自己控管的錢包，可以降低對第三方提領服務的依賴，但金鑰、權限、備援和事故處理的責任也會回到企業身上。這正是下面第三個風險要談的。

## 風險二：遭竊資金流進企業錢包

部分被盜資產已經被兌換或跨鏈轉移。Bitquery 的分析顯示，攻擊者在幾個小時內就透過去中心化交易所把穩定幣換成 ETH 和 TRX，再經由幾座跨鏈橋把資金轉走。不過 Bitquery 的追蹤也顯示，還有大量資產留在攻擊者相關的地址，沒有再轉出，後續動向仍待追蹤。

FBI 公布調查結果時，也要求民間業者封鎖跟洗錢地址有關的交易。據 [CoinDesk 報導](https://www.coindesk.com/policy/2026/10/31/fbi-confirms-north-korea-s-role-in-usd6-billion-binance-hack-asks-defi-community-to-block-btc-eth-sol-addresses)，名單上有 600 多個以太坊地址、大約 20 個比特幣地址和 1 個 Solana 地址。追查越深入，這類名單通常越長，事發後幾天內，調查結論也可能改變。

別人要把錢轉進企業的公開地址，企業擋不了，但收到之後怎麼處理，企業可以決定。款項在鏈上到帳後，應該先完成風險篩查，再依內部政策決定是否列為客戶可用的餘額、出貨，或進一步動用。篩查命中風險標記，代表需要進一步了解，不等於下了結論：企業仍要檢視這筆錢跟風險地址是直接還是間接關聯、交易背景和付款資料，再決定是否深入審查。地址被標記之前就已經收下的款項，也可能要回頭再查。

專屬收款地址在這裡也有幫助。每張發票都有自己的地址，就比較容易把鏈上收款對應到訂單或客戶帳戶，萬一之後來源被標記，也比較好追查。不過付款人的身分和資金來源，仍要搭配客戶資料和交易紀錄確認，因為可能有第三方代付，也可能收到預期之外的轉帳。

穩定幣還有一個特點。Tether、Circle 等發行商有時在幾分鐘內就凍結了攻擊者手上大量的 USDT 和 USDC；比特幣、以太幣這類原生資產沒有發行商，沒辦法這樣凍結。凍結限制了攻擊者能動用的資金，但不等於已經追回或歸還。發行商具備對自家代幣執行地址凍結的技術能力，企業自己持有的穩定幣同樣適用發行商的規定。這也是企業要清楚掌握收款來源，並保留紀錄證明自己的地址用在正當業務的原因之一。

*KryptoGO 觀點*：對收穩定幣的企業來說，這次事件提醒我們，風險篩查不能在收款那一刻就結束。新的地址情資陸續出來，篩查也要跟著做。

## 風險三：企業自己的簽署流程

第三個風險在企業內部。幣安表示沒有發現錢包私鑰外洩的證據，調查則指出，未經授權的提領是從內部系統送出的。對企業來說，這代表只防範私鑰外洩還不夠，也必須防止攻擊者濫用有權要求簽署的系統。即使私鑰一直留在受保護的環境裡，未經授權的交易仍可能取得有效簽章。

換到規模小一點的公司，可能是這樣的情況：某個員工的帳號可以自己建立轉帳、自己核准；付款工具只要收到財務系統送來的交易就會簽；或是錢包的核准畫面只顯示摘要，看不到實際的交易內容。這些情況不需要私鑰被偷，就可能造成損失。

該怎麼防，我們在 [Maker、Approver 與 Signer 角色指南](https://www.kryptogo.com/blog/maker-approver-signer-enterprise-wallet)裡有完整說明：核准要對應到實際簽署的那一筆交易，金額大的付款要有獨立的核准人，設定每天能轉出的上限，並且要能很快暫停簽署。

以太坊方面，[Fireblocks](https://www.fireblocks.com/blog/binance-hack-eip-7702) 和 Bitquery 的分析指出，攻擊者用一筆簽好的 EIP-7702 授權，把幣安的一個熱錢包委派給惡意合約。Fireblocks 特別說明，攻擊者是新建了一筆授權，不是破解原本就有的 EIP-7702 合約，而且這個機制無法解釋比特幣和 TRON 上的資金移動。也就是說，這項分析說明的是以太坊上的部分攻擊路徑，不能用來解釋這次所有鏈上的資金流出。依照 [EIP-7702 規格](https://eips.ethereum.org/EIPS/eip-7702)，這種委派會一直有效，直到帳戶自己變更或清除。在以太坊及已支援 EIP-7702 的相容網路上使用錢包的企業，除了對外轉帳，也要把委派變更和新的合約互動當成高風險操作來管。

## 企業現在該檢查什麼？

如果你的公司有持有、收取或支付穩定幣，可以趁這次機會檢查三件事，剛好對應三個風險。

**放在第三方的錢** 列出所有幫公司保管資金的交易所、託管機構和支付服務商，以及每一家放了多少。逐一想好：萬一這筆錢一週領不出來，公司要怎麼繼續付供應商和員工，以及有沒有備用的付款管道。

**收到的款項** 確認收到穩定幣後，是不是先篩查才開放使用、命中風險標記時由誰怎麼審查，以及風險資料會不會隨著新標記的地址更新。10 月 29 日以後收到的款項，建議用最新名單再查一次。

**自己的簽署流程** 弄清楚哪些人、哪些系統和裝置可以送出交易去簽署，有沒有哪個帳號能自己建立、自己核准付款。也要確認核准人和簽署人看到的是實際的交易內容，而且核准後只要內容改了，就會退回重審。

另外，建議事先建立好通報窗口和處理流程，涵蓋穩定幣發行商、交易所和鏈上分析服務商，萬一公司自己的資金出事，才能縮短反應時間。

## KryptoGO 能協助您的地方

上面這些檢查，企業都可以自己先開始做。如果過程中發現缺口，以下是 KryptoGO 能協助的部分，一樣對應這三個風險。各項功能的適用範圍，依企業使用的產品和串接方式而定。

**放在第三方的錢**如果企業選擇自己持有部分營運資金，KryptoGO 的企業錢包基礎設施提供角色權限和核准流程，讓自持資金一開始就有自行保管所需的簽署與權限控管。

**收到的款項混入遭竊資金**KryptoGO 的交易監控會篩查付款來源的地址，讓企業在開放使用資金前先檢視結果。KryptoGO 也能為每張發票自動產生專屬收款地址，協助把鏈上收款對應到訂單或客戶帳戶。面對新的企業客戶或合作對象，KYB 能驗證對方的企業身分；但驗證企業身分，不等於證明對方每一筆付款的來源都沒有風險。

**簽署流程被濫用**核准流程和地址白名單，能協助落實 Maker、Approver 與 Signer 指南裡的控管做法；稽核紀錄則能記錄每筆轉帳是誰發起、誰核准、誰簽署。

**想檢視公司的第三方資金曝險、收款篩查和核准控管，歡迎與 KryptoGO 聯繫**

*本文僅供一般資訊參考，不構成法律、資安或法遵建議。內容反映截至 2026 年 11 月 3 日（台北時間）的公開資訊*

## 常見問題

### 把錢放在幣安的企業有受到影響嗎？

幣安表示將承擔損失。對依賴這家交易所的企業來說，主要的影響是暫停提領。從暫停到 11 月 1 日開始分階段恢復，大約兩天半。

### 幣安被盜的錢可能流到我的公司嗎？

有可能。部分被盜資金已經在不同網路之間兌換、轉移，有些可能透過一般付款流到普通企業。篩查收到的款項、回頭檢查最近的收款，能幫企業找出和管理這個風險，但沒辦法阻止別人把錢轉進公開地址。

### 被凍結的錢追回來了嗎？

不一定。凍結只是讓攻擊者動不了這些代幣，追回和歸還是另外的步驟。本文引用的公告尚未列明已追回並返還的金額，幣安用來補損失的錢來自公司自己的準備。

### 幣安被盜是誰做的？

FBI 在 2026 年 10 月 31 日指出，這起竊案是北韓駭客組織 TraderTraitor 所為。

## 參考資料

- Binance, [*Security Incident Update #2*](https://www.binance.com/en/support/announcement/detail/d3306d9dca5243548c813b605e1d1751), 2026 年 10 月 30 日。
- Federal Bureau of Investigation, [*North Korea Responsible for $6 Billion+ Binance Attack*](https://www.fbi.gov/investigate/cyber/alerts/2026/north-korea-responsible-for-6-billion-binance-attack), 2026 年 10 月 31 日。
- CoinDesk, [*FBI confirms North Korea's role in $6 billion Binance hack*](https://www.coindesk.com/policy/2026/10/31/fbi-confirms-north-korea-s-role-in-usd6-billion-binance-hack-asks-defi-community-to-block-btc-eth-sol-addresses), 2026 年 10 月 31 日。
- Elliptic, [*The largest theft in history: North Korea likely behind the $6.4 billion Binance hack*](https://www.elliptic.co/insights/binance-largest-hack-in-history/), 2026 年 10 月。
- Bitquery, [*Binance Hack: $6.3B Drained on 9 Chains*](https://bitquery.io/investigations/binance-hack), 2026 年 10 月。
- PYMNTS, [*Binance Says It Replaced 95% of Stolen Crypto for Users*](https://www.pymnts.com/cryptocurrency/2026/binance-says-it-replaced-95-percent-of-stolen-crypto-for-users/), 2026 年 11 月 1 日。
- Fireblocks, [*Deconstructing the Binance Exploit*](https://www.fireblocks.com/blog/binance-hack-eip-7702), 2026 年 10 月 30 日。
- Ethereum Improvement Proposals, [*EIP-7702: Set Code for EOAs*](https://eips.ethereum.org/EIPS/eip-7702)。

幣安被盜後暫停提領約兩天半，放在交易所的錢只能等。用穩定幣收付款的企業，現在該檢查三件事：錢放在哪裡、收到的錢來源有沒有問題、誰能簽出一筆轉帳。

幣安被盜 63 億美元，用穩定幣收付款的企業要注意這三件事

Binance Hack: What It Means for Businesses Using Stablecoins

A company needs to pay a supplier in USDC. Someone in operations enters the address and amount, finance checks the invoice and budget, and an authorized signer releases the transfer. But if the address or amount changes after finance approves it, is that approval still valid?

It should not be. Separating Maker, Approver, and Signer roles only works when what was approved is exactly what gets signed, and when anyone can later reconstruct who requested, who approved, and who signed each payment.

## Key takeaways

- Wallet governance depends on whether the payment reason, the approval, the signing authorization, and the transaction record all refer to the same transaction.
- Multisig and MPC control how many keys must sign. They do not, on their own, control who may request a payment, what an approver must check, or whether the signed transaction matches the approved one.
- Any change to the destination, amount, asset, or network after approval should cancel the approval and send the request back for review.
- Policy changes, new addresses, split payments, and staff departures are the points where role separation is most often bypassed, so each needs its own control.

## Why one enterprise payment needs three separate roles

When one person can create, approve, and sign a transfer, a single compromised account, a single mistake, or a single dishonest employee is enough to move funds. Because blockchain transfers are generally difficult to reverse, there is little chance to correct the error afterwards. Separating the steps is the same separation-of-duties principle used across financial controls, which the [NIST security and privacy controls catalog (SP 800-53, control AC-5)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) describes as identifying duties that require separation and enforcing that separation through access authorizations.

For a company that has been paying suppliers from a wallet controlled by one person, the risk is easy to underestimate. Nothing goes wrong until the day the address is wrong, the laptop is compromised, or the person leaves.

## Where each role's responsibility begins and ends

The **Maker** creates the payment request. Their responsibility is completeness and accuracy: the right destination, amount, asset, and network, with the business reason and supporting documents attached. The Maker should never be able to approve or sign their own request.

The **Approver** decides whether the company should make the payment. Their responsibility is the business judgment: the invoice is genuine, the counterparty has been verified, the amount fits the budget, and the payment is within policy. An Approver who only clicks "approve" on a summary, without seeing these details, is not providing a real check.

The **Signer** provides the cryptographic authorization that lets the transaction be submitted onchain. Their responsibility is narrow but critical: confirming that the transaction they are about to sign is the one that was approved, and protecting the key, key share, or device they control. Depending on the wallet design, a Signer may hold a private key, a share in a multi-party computation (MPC) setup, or one of several keys in a multisig wallet.

In a small team, one person may hold more than one role. When that happens, the company should know which control it has given up and what compensates for it, such as lower limits or an additional reviewer after the fact.

## What does multisig control, and what does it leave open?

Multisig and MPC enforce a signing threshold: a transaction is only valid when enough keys or key shares take part. That is valuable, and industry standards such as the [CryptoCurrency Security Standard](https://cryptoconsortium.org/2026/02/24/cryptocurrency-security-standard-ccss-aspect-1-02/) treat multi-signer configurations held by distinct operators as best practice.

A signing threshold does not, however, define who may create a payment request, what each approver must verify, or whether the transaction presented for signing is the one the business approved. A wallet can require three signatures and still lack a meaningful approval process if the signers are only confirming that a request arrived.

The gap became visible in February 2025, when attackers stole approximately USD 1.5 billion in digital assets from a major cryptocurrency exchange, a theft the [FBI attributed to North Korea](https://www.ic3.gov/PSA/2025/PSA250226). According to [investigations reported by BleepingComputer](https://www.bleepingcomputer.com/news/security/lazarus-hacked-bybit-via-a-breached-safe-wallet-developer-machine/), the attackers compromised a developer machine at the wallet interface provider and injected code that disguised a malicious transaction as a routine transfer. A multisig transaction of this kind can only execute once it collects the required signatures, so the signing threshold worked. What failed was the link between what the signers were shown and what they actually authorized.

## How do you keep the approved transaction and the signed transaction the same?

Tie each approval to the exact transaction it covers, and show signers what that transaction actually does. This is the control most often missing from enterprise wallet setups, and the one that matters most, because an approval should apply to one specific transaction rather than to a payment in general.

In practice, that means the approval is tied to the exact parameters of the request: destination address, amount, asset, network, and any contract call. If any of these change after approval, the approval should be cancelled automatically and the request should return to the Approver. A corrected typo in the address is still a new destination, and it deserves a new decision.

It also means the Signer should see the transaction details decoded from the actual transaction data, not a description generated by the system that created the request. If the two are produced by the same compromised component, a disguised transaction can look entirely normal.

*KryptoGO analysis:* when companies describe their wallet controls, they usually describe who can approve. The more useful question is what happens to an approval when the request changes. If the answer is "nothing," the approval step can be bypassed by editing the request after it has been approved.

## Turning role separation into policy

Role separation becomes reliable when it is written into rules that the wallet enforces, rather than habits that people follow. Five situations deserve explicit rules.

**A change after approval.** Any change to the destination, amount, asset, or network cancels the approval. The request goes back through the full approval path.

**A new receiving address.** Adding an address to the allowlist should be controlled separately from paying it. The address should be linked to a verified counterparty, screened for sanctions and other risk exposure, and approved by someone other than the requester. A short waiting period before first use gives the team a chance to notice an unauthorized addition.

**Several small payments on the same day.** Approval thresholds should consider cumulative amounts over a day or a rolling period. Otherwise, a large payment can be split into smaller ones that each stay below the review threshold. As an illustration, a policy might allow one approver for routine transfers to allowlisted addresses, require two approvers from different functions for larger or first-time payments, and require a senior approver plus a signing quorum above a set limit. The right tiers depend on each company's risk appetite.

**A change to the rules themselves.** If one administrator can raise limits, add a signer, or remove an approval step alone, every other control can be bypassed. Policy changes should need independent approval and should be logged like transactions.

**A signer who leaves.** Removing the person's access on the day they leave is only the first step. The company also needs to confirm that the signing threshold can still be met without them, that recovery still works, and that any requests they created or approved are reviewed.

## Making every payment traceable

After an incident or during an audit, the company should be able to answer four questions for any payment: who requested it, who approved it, who signed it, and whether the signed transaction matched the approved one. That requires logs that link the request and its documents to each approval decision, the signing participants, and the resulting TxID, along with failed or cancelled attempts and every change to users, roles, limits, and allowlists.

These records serve two purposes. Security teams use them to investigate incidents, and finance teams use them in month-end reconciliation to show that every outgoing transfer was authorized.

## Questions for evaluating a wallet's governance

When a company is choosing or reviewing an enterprise wallet, a few questions reveal more than a feature list. Does an approval become invalid if the request changes? Do approvers and signers see details decoded from the transaction itself? Are new addresses controlled separately from payments to them? Do thresholds apply to cumulative amounts? Can one administrator change the approval rules alone? What happens to the signing threshold when a signer leaves? And can the company export a complete record linking each payment's reason, approval, signature, and onchain transaction?

If the answers are unclear, the company likely needs to design its governance before it needs more wallet functionality.

## How KryptoGO approaches wallet governance

KryptoGO treats an enterprise payment as a sequence of checks rather than a single signing event. First, has the counterparty completed the required KYC or KYB verification? Next, have the receiving address and the transaction been screened for risk? Then, has the payment been approved by the right people under the company's permission rules? Does the transaction being signed match what was approved? And finally, is the record complete enough for reconciliation and investigation?

KryptoGO's enterprise wallet infrastructure supports role-based permissions, approval workflows, address allowlists, and audit records, and connects with KYC, KYB, and transaction monitoring, so that these checks can run in order on the same payment.

**Use the Enterprise Wallet Governance Checklist to review how your roles, approvals, address controls, and records work together.**

*This article is for general information only and does not constitute legal, security, or compliance advice. The appropriate control design depends on each organization's size, risk profile, regulatory obligations, and wallet architecture.*

## Frequently asked questions

### Does MPC remove the need for an approval workflow?

No. MPC changes how keys are generated and used, but it does not decide whether a payment is legitimate. Business approval still needs to happen before signing.

### How many approvers should a company require?

There is no universal number. Most companies scale the number of approvals with the amount and risk of the payment, and require at least one approver who is independent of the requester.

### Can a non-custodial wallet support enterprise governance?

Yes, if its control model supports role separation, approvals tied to specific transactions, address controls, recovery, and audit records. The deciding factor is the governance model, not whether the wallet is custodial or non-custodial.

### How often should wallet permissions be reviewed?

On a regular schedule set by internal policy, and immediately after any role change, departure, or security incident.

## Sources

- National Institute of Standards and Technology, [*SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations*](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), control AC-5, Separation of Duties.
- CryptoCurrency Certification Consortium (C4), [*CryptoCurrency Security Standard, Aspect 1.02: Wallet Creation and Signing*](https://cryptoconsortium.org/2026/02/24/cryptocurrency-security-standard-ccss-aspect-1-02/), February 2026.
- Federal Bureau of Investigation, [*North Korea Responsible for $1.5 Billion Bybit Hack*](https://www.ic3.gov/PSA/2025/PSA250226), Public Service Announcement I-022625-PSA, 26 February 2025.
- BleepingComputer, [*Lazarus hacked Bybit via breached Safe{Wallet} developer machine*](https://www.bleepingcomputer.com/news/security/lazarus-hacked-bybit-via-a-breached-safe-wallet-developer-machine/), February 2025.

金色鑰匙與神秘金庫門 KryptoGO 封面.png

In an enterprise wallet, the Maker requests, the Approver decides, and the Signer executes. How to set thresholds, allowlists, offboarding, and audit logs.

What Are Maker, Approver, and Signer Roles in an Enterprise Wallet?

**Finance teams reconcile stablecoin payments at month end by linking every onchain transaction to a wallet the company controls, a counterparty, a business document, an approval record, a pricing source, and a ledger entry, then proving that wallet balances at the cutoff time agree with the general ledger. A TxID shows that a transfer happened. It does not, on its own, show why it happened or how it should be booked.**

## Key takeaways

- Stablecoin reconciliation has no bank statement to rely on, so the company has to build its own record from blockchain data, wallet registers, and business documents.
- A TxID is strong evidence that a transfer occurred, but it usually needs to be combined with counterparty, invoice, approval, and pricing records before it supports an accounting entry.
- Internal transfers, network fees paid in a separate native token, and the choice of cutoff time are the most common sources of month-end differences.
- How a stablecoin is classified and measured depends on its terms and on the reporting framework, so the close process should follow a documented accounting policy agreed with auditors.

## Why is stablecoin reconciliation different from bank reconciliation?

**Stablecoin reconciliation is different because there is no bank statement: the company must assemble the equivalent from public blockchain data and its own records.** In a bank reconciliation, the bank provides an authoritative list of transactions, a closing balance, and usually some payer information. With stablecoins, the blockchain provides transactions and balances, but nothing else.

That gap creates several practical differences:

- **No counterparty names onchain.** A transfer shows wallet addresses, not who sent the funds or which invoice they were paying.
- **Many accounts, many networks.** The same stablecoin can sit on several blockchains, in self-managed wallets, with custodians, and on exchange accounts.
- **No natural cutoff.** Blockchains run continuously, so the company has to choose and document the exact moment that defines month end.
- **Fees in a different asset.** Network fees are often paid in the chain's native token rather than in the stablecoin itself.
- **Classification varies.** Depending on the stablecoin's terms and the reporting framework, a holding may be treated differently, which affects measurement and presentation.

## What records should finance teams collect?

**For each stablecoin transaction, finance teams should collect the onchain data, the business context, and the control evidence in one place.** A practical minimum record includes:

- **Onchain data:** TxID, blockchain network, token contract address, sending and receiving addresses, amount, block number, block timestamp, and confirmation status.
- **Wallet ownership:** which company entity controls each address involved, and whether it is a self-managed wallet, a custodian account, or an exchange account.
- **Counterparty:** the verified customer or supplier behind the external address, linked to its KYC or KYB record.
- **Business document:** the invoice, order, contract, or intercompany agreement the transfer relates to.
- **Approval record:** who initiated, approved, and signed outgoing transfers, with timestamps.
- **Pricing and fees:** the price or exchange rate applied, its source and timestamp, and the network fee with the asset it was paid in.

The most useful single control is an **address register**: a maintained list of every address the company controls, by entity, network, and purpose. Without it, completeness and internal-transfer checks become guesswork.

## How should TxIDs be matched with invoices?

**Match TxIDs to invoices by designing payment instructions that make matching possible, then recording each match in a subledger.** Stablecoin transfers rarely carry a reliable payment reference, so matching on amount and date alone breaks down as volume grows.

Common approaches include:

- **Unique receiving addresses** per customer or per invoice, so the receiving address itself identifies the payer.
- **Exact-amount invoicing**, where small amount differences act as identifiers, with a defined tolerance for rounding.
- **Memo or tag fields** on networks that support them.
- **Pre-registered payer addresses** collected during onboarding, so incoming funds can be attributed to a known counterparty.

Exceptions need defined handling: partial payments, overpayments, one transfer covering several invoices, payments from an unregistered address, and funds sent on the wrong network. Each exception should leave a documented resolution, not just a manual adjustment.

## How are internal wallet transfers identified?

**Internal transfers are identified by checking both sides of each transaction against the address register.** If both addresses belong to the same entity, the transfer moves funds between the company's own accounts and should not create revenue, expense, or a payable. If the addresses belong to different group entities, the transfer is intercompany and needs matching entries on both sides.

Movements to and from custodians or exchange accounts deserve particular care, because the receiving address may be shared or controlled by the provider. Reconcile those against the provider's account statement rather than relying only on the blockchain view.

## How should network fees be treated?

**Network fees should be captured for every outgoing transaction and accounted for under a written policy, because the appropriate treatment depends on the reporting framework and the nature of the transaction.** In practice, companies decide whether fees are expensed as incurred or treated as part of the cost of a related transaction, and apply that choice consistently.

Two operational points matter regardless of the policy:

- Fees are often paid in the network's native token, which means the company also holds a second digital asset that must be tracked, valued, and reconciled.
- Fees should be recorded per transaction from the blockchain data, not estimated, so that wallet balances reconcile to the ledger.

## Which pricing source should be used?

**Use a documented pricing source and a fixed cutoff timestamp, applied consistently every period, and record both with each valuation.** Even dollar-referenced stablecoins can trade slightly away from their reference value, and the company may also need an exchange rate into its functional currency, such as New Taiwan dollars or euros.

A pricing policy typically defines:

- The source or sources used, and the fallback if a source is unavailable.
- The cutoff time and time zone, for example 23:59:59 in the reporting entity's local time, or a UTC equivalent.
- A threshold for when a deviation from the reference value requires review rather than automatic acceptance.
- The exchange rate source for translation into the functional currency.

Whether fair value measurement applies at all depends on classification. In the United States, ASU 2023-08 requires fair value for crypto assets within its scope, but [Deloitte's implementation guidance](https://dart.deloitte.com/USDART/home/publications/deloitte/heads-up/2024/faq-fasb-crypto-assets-standard-asu-2023-08) notes that the standard excludes assets that give the holder enforceable rights to underlying assets, and that each stablecoin's terms must be evaluated. On 18 August 2026, the FASB issued a [proposed update](https://storage.fasb.org/Proposed%20ASU%20Statement%20of%20Cash%20Flows%20%28Topic%20230%29.pdf) to clarify when certain digital assets may be classified as cash equivalents; it is open for comment until 19 November 2026 and is not yet final. Under IFRS, the IFRS Interpretations Committee's [2019 agenda decision](https://www.ifrs.org/content/dam/ifrs/supporting-implementation/agenda-decisions/2019/holdings-of-cryptocurrencies-june-2019.pdf) addressed cryptocurrencies that do not give rise to a contract with another party, so stablecoins with contractual redemption rights call for separate analysis.

*KryptoGO analysis:* the classification decision should be made once, documented, and reviewed with auditors before the first close, not revisited informally each month.

## How are wallet balances reconciled with the ledger?

**Reconcile by comparing each wallet's onchain balance at the cutoff block with the general ledger balance for that wallet, then explaining every difference.** Identify the last block at or before the cutoff timestamp on each network, read the balance of each registered address at that block, and compare it with the ledger.

Typical reconciling items include:

- Transfers submitted before cutoff but confirmed after it
- Network fees not yet recorded
- Unrecorded incoming transfers, including unsolicited tokens sent to company addresses
- Balances held with custodians or exchanges, which should be confirmed against provider statements
- Amounts restricted or frozen by an issuer or service provider

Every difference should be investigated, explained, and either corrected or carried forward with a documented reason.

## What evidence will auditors need?

**Auditors generally need evidence that balances exist, that the company controls them, that the records are complete, that cutoff is correct, and that valuation follows the stated policy.** Blockchain data supports existence and occurrence, but it does not prove ownership or business purpose on its own.

Evidence commonly requested includes:

- The address register and evidence that the company controls each address, such as a signed message or a test transfer
- Onchain balance extracts at the cutoff block
- Custodian or exchange statements, and service organization control reports where available
- Transaction-level records linking TxIDs to counterparties, invoices, and approvals
- The pricing policy, sources, and cutoff timestamps used
- Access and signing controls, including who can approve and sign transfers

The AICPA's nonauthoritative practice aid, *Accounting for and Auditing of Digital Assets*, is a common reference point for these discussions in the United States. Requirements in other jurisdictions may differ.

## What belongs in the month-end checklist?

**A stablecoin month-end checklist should cover data capture, classification, matching, valuation, balance reconciliation, review, and evidence retention.** A workable sequence:

1. Confirm the address register is complete and current for every entity, network, and provider account.
2. Fix the cutoff timestamp and identify the cutoff block on each network.
3. Extract all transactions for the period for every registered address.
4. Classify each transaction as customer receipt, supplier payment, internal transfer, intercompany, fee, or exception.
5. Match external transactions to counterparties, invoices, and approval records.
6. Record network fees per transaction in the asset actually used to pay them.
7. Apply the pricing and exchange rate policy and store the source and timestamp.
8. Reconcile onchain and provider balances to the general ledger and document every difference.
9. Review and approve the reconciliation, with separation between preparer and reviewer.
10. Archive the evidence pack for the period in a form auditors can access.

## KryptoGO perspective

Most month-end problems start earlier in the payment flow: a counterparty that was never linked to an address, an approval that lives in a chat message, or a wallet that was never added to the register. KryptoGO provides enterprise wallets, KYC and KYB, and transaction monitoring designed to keep counterparty, approval, and transaction records connected from the moment a payment is created, so that finance teams start the close with fewer gaps to fill.

**Download the Stablecoin Month-End Close Checklist to review your records, pricing policy, and reconciliation steps.**

*This article is for general information only and does not constitute accounting, audit, tax, or legal advice. Accounting treatment depends on each stablecoin's terms, the applicable reporting framework, and the company's facts and circumstances. Consult your auditors and advisers.*

## Frequently asked questions

### Are stablecoins cash equivalents?

Not automatically. It depends on the stablecoin's terms, such as redemption rights and reserve arrangements, and on the reporting framework. In the United States, the FASB's August 2026 proposal on digital assets as cash equivalents is still under consultation.

### Which time zone should define month end?

Any consistent, documented choice can work, as long as it matches how the company closes its other accounts and is applied the same way each period. Many companies use the reporting entity's local midnight; others use UTC. The key is to record the cutoff block for each network.

### What happens if a customer sends funds on the wrong network?

The funds may be recoverable, delayed, or lost, depending on the address and the network. Record the transfer as an exception, keep it out of normal receivables matching until resolved, and document the outcome.

### Do we need a separate receiving address for each customer?

It is not required, but unique receiving addresses per customer or invoice make matching much easier. Companies that use a single address usually need stronger reference or amount-matching controls.

### Should reconciliation only happen at month end?

Daily or weekly matching reduces the month-end workload and catches errors sooner. The month-end close then becomes a review and balance confirmation rather than a full rebuild.

### Who should own stablecoin reconciliation?

Finance typically owns the reconciliation and accounting entries, while operations or treasury owns the address register and payment execution, and compliance owns counterparty verification. Clear ownership of each record is more important than which team does the work.

## Sources

- FASB, [*Proposed Accounting Standards Update: Statement of Cash Flows (Topic 230), Cash Equivalents: Disclosure Enhancement and Evaluation of Certain Digital Assets*](https://storage.fasb.org/Proposed%20ASU%20Statement%20of%20Cash%20Flows%20%28Topic%20230%29.pdf), 18 August 2026.
- Deloitte, [*Frequently Asked Questions About Implementation of the FASB's New Crypto Assets Standard (ASU 2023-08)*](https://dart.deloitte.com/USDART/home/publications/deloitte/heads-up/2024/faq-fasb-crypto-assets-standard-asu-2023-08), 2024.
- IFRS Interpretations Committee, [*Holdings of Cryptocurrencies*, agenda decision](https://www.ifrs.org/content/dam/ifrs/supporting-implementation/agenda-decisions/2019/holdings-of-cryptocurrencies-june-2019.pdf), June 2019.
- AICPA, *Accounting for and Auditing of Digital Assets* (nonauthoritative practice aid).

穩定幣到站解釋.png

Stablecoin reconciliation links each TxID to a wallet, counterparty, invoice, approval, and price. A month-end close framework for finance and audit teams.

How Should Finance Teams Reconcile Stablecoin Payments at Month End?

**KYB onboarding slows down across borders mainly because company records, ownership structures, and beneficial ownership (UBO) evidence follow different standards in every jurisdiction, and the cases that do not fit a standard path need human review. The application form is rarely the bottleneck. The delay sits in verifying data that was never designed to be compared across countries.**

## Key takeaways

- KYB verifies a legal entity, its ownership and control, and the people behind it; that makes it structurally slower than individual KYC.
- Cross-border delays come from inconsistent registry data, multi-layer ownership chains, UBO evidence gaps, and document translation or certification, not from the onboarding form.
- Registry lookups, document checks, sanctions screening, and wallet screening can be largely automated; complex ownership, discrepancies, and higher-risk cases still need a trained reviewer.
- The most effective redesign separates the straight-through path from the exception path and defines, in advance, which evidence resolves which exception.

## What is KYB in cross-border payments?

**KYB (Know Your Business) is the due diligence a regulated firm performs to confirm that a business customer exists, understand who owns and controls it, and assess the risk of the relationship.** Under [FATF Recommendation 10](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html), customer due diligence for a legal person includes identifying and verifying the entity, understanding its ownership and control structure, and identifying its beneficial owners.

In cross-border payments, KYB is usually performed by the payment provider, VASP, bank, or platform that onboards the business. The counterparty may be incorporated in one country, operate in a second, and hold accounts or wallets in a third, and each of those facts can change what evidence is needed.

## Why does KYB take longer than KYC?

**KYB takes longer because it verifies a structure, not a single person.** An individual's KYC typically confirms one identity against one document. A business check has to confirm the entity, its registered details, its directors and authorized signatories, every intermediate owner, and the natural persons at the top of the chain.

How KYC and KYB compare:

- **Subject:** KYC covers one natural person. KYB covers a legal entity plus the people who own or control it.
- **Core evidence:** KYC relies on an ID document, liveness check, and address. KYB needs a registry extract, constitutional documents, an ownership chart, and the identities of UBOs and directors.
- **Data sources:** KYC usually draws on one issuing authority. KYB draws on company registries, UBO registers, filings, and customer-supplied documents across several jurisdictions.
- **Typical failure point:** For KYC, document quality or a mismatch. For KYB, ownership gaps, registry discrepancies, and intermediate entities that cannot be verified.
- **Review trigger:** For KYC, a sanctions or PEP hit. For KYB, an opaque structure, nominee arrangements, a high-risk jurisdiction, or a business model that does not fit.

Industry data shows the cost of getting this wrong. In Fenergo's 2025 survey of 600 financial institutions in the UK, US, and Singapore, 70% said they had lost clients in the past year because of inefficient onboarding, and UK corporate banks reported onboarding times of more than six weeks ([Fenergo, October 2025](https://www.fenergo.com/newsroom/global-financial-institutions-struggle-with-rising-client-losses-and-compliance-costs-as-ai-adoption-increases-fenergo)).

## Which records need verification?

**Most KYB programs verify four groups of records: entity existence, control, ownership, and business activity.** The exact list depends on the firm's risk policy and the applicable regulation.

- **Entity:** legal name, registration number, jurisdiction of incorporation, registered address, legal form, status (active, dissolved, struck off), and where available a Legal Entity Identifier (LEI).
- **Control:** directors, authorized signatories, and evidence of their authority to open the relationship.
- **Ownership:** shareholder register or ownership chart down to the natural persons, plus identity verification of each beneficial owner.
- **Activity:** nature of business, expected transaction volumes and corridors, source of funds, and, for digital asset flows, the wallets or accounts that will be used.

Standard identifiers help but are not universal. More than 3.1 million entities held an active LEI at the end of Q2 2026 ([GLEIF](https://www.gleif.org/en/newsroom/blog/the-lei-in-numbers-q2-2026-signals-growing-regional-momentum-for-the-lei)), a small fraction of the companies that open cross-border payment relationships.

## Why is UBO verification difficult?

**UBO verification is difficult because ownership rules, registry access, and data quality differ by jurisdiction, and multi-layer structures must be traced entity by entity.** A beneficial owner is the natural person who ultimately owns or controls a customer. Many regimes use a 25% ownership threshold as a starting point, but control can also exist without shareholding.

Several regulatory developments illustrate the variation (status as of September 2026):

**International: FATF Recommendation 24**

- Status: international standard, revised March 2022, with guidance published March 2023; implementation varies by country.
- Relevance: calls for adequate, accurate, and up-to-date beneficial ownership information through a multi-pronged approach rather than a single source ([FATF Guidance on Beneficial Ownership of Legal Persons](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-Beneficial-Ownership-Legal-Persons.html)).

**European Union: Anti-Money Laundering Regulation (EU) 2024/1624**

- Status: adopted; applies from 10 July 2027.
- Relevance: harmonizes a 25% ownership test combined with a control test and interconnects national beneficial ownership registers ([Regulation (EU) 2024/1624, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/1624/oj/eng)).

**United States: FinCEN final rule under the Corporate Transparency Act**

- Status: issued 11 August 2026; published and effective 14 August 2026.
- Relevance: removes beneficial ownership information reporting for US companies and US persons; foreign entities registered to do business in the US may still have to report ([Federal Register, 2026-16576](https://www.federalregister.gov/documents/2026/08/14/2026-16576/beneficial-ownership-information-reporting-requirement-revision)).

The practical result is that the same UBO question may be answerable from a register in one country, only from customer-supplied documents in another, and only partly in a third. Each intermediate holding company adds another registry lookup, another document set, and often another language.

*KryptoGO analysis:* the most common source of delay is not missing data but conflicting data, for example a registry extract that lists different directors from the customer's own documents, or an ownership chart whose percentages do not reconcile. Resolving a conflict takes longer than collecting a missing file.

## How do KYC, KYB, KYA, and KYT connect?

**They are four layers of the same onboarding and monitoring picture: the people, the business, the wallet or account, and the transactions.**

- **KYC:** Who are the individuals (directors, signatories, UBOs)? Runs at onboarding and periodic review.
- **KYB:** What is the business, and who owns and controls it? Runs at onboarding and periodic review.
- **KYA (address or account screening):** Is the wallet or account the business will use linked to sanctioned or high-risk activity? Runs before first use and before each new address is allowlisted.
- **KYT:** Are the transactions consistent with the expected profile? Runs continuously after onboarding.

For digital asset and stablecoin flows, this link matters. A business that passes KYB can still present risk if its declared wallet has exposure to sanctioned or illicit activity, and KYT alerts are easier to assess when the KYB profile already defines expected counterparties, corridors, and volumes. Where a VASP is on either side of a transfer, Travel Rule obligations also require originator and beneficiary information to accompany it, and that information depends on the customer data collected during onboarding.

## Which steps can be automated?

**Retrieval, extraction, matching, and screening are the strongest candidates for automation; judgment about risk and exceptions is not.**

**High automation potential**

- Registry lookup and entity status, where an official or licensed data source exists for the jurisdiction.
- Document classification and data extraction; accuracy depends on document quality and language.
- Name, address, and registration matching; rules for acceptable variance should be defined in policy.
- Sanctions, PEP, and adverse media screening for detection; resolving hits may still need review.
- Wallet or address screening for detection; risk thresholds remain a policy decision.

**Medium automation potential**

- Ownership chart construction: straightforward for simple structures, limited for trusts, nominees, and bearer arrangements.
- Risk scoring: inputs can be automated, but the methodology is owned by people.

**Low automation potential**

- Exception resolution and approval of high-risk cases, which require trained reviewers and a documented rationale.

## Which cases need manual review?

**Manual review is typically reserved for cases where evidence conflicts, ownership is opaque, or risk indicators exceed policy thresholds.** Common triggers include:

- Registry data that conflicts with customer-supplied documents
- Ownership chains with more than one or two intermediate entities, or entities in jurisdictions without accessible registers
- Trusts, foundations, nominee shareholders, or bearer-share arrangements
- Sanctions, PEP, or adverse media matches that automated rules cannot clear
- Business activity, corridors, or volumes that do not fit the stated model
- Wallets or accounts with material exposure to high-risk categories

## How should KYB onboarding be redesigned?

**Redesign KYB onboarding around two paths: a straight-through path for cases that meet defined evidence rules, and an exception path with named owners, evidence requirements, and service levels.**

1. **Map requirements by jurisdiction and risk tier** before building forms, so each customer is only asked for what applies to them.
2. **Pull before you ask.** Retrieve registry and LEI data first and ask the customer only to fill gaps.
3. **Collect ownership once, in structure.** Capture the ownership chain as data, not as an uploaded diagram.
4. **Define discrepancy rules.** Decide in advance which mismatches are tolerated, which need a document, and which need escalation.
5. **Connect KYB to KYA and KYT.** Record expected wallets, counterparties, and volumes at onboarding so monitoring has a baseline.
6. **Measure the exception path.** Track time in each exception state, not only total onboarding time.

This approach does not lower the standard of due diligence; it makes the standard predictable for both the business customer and the reviewer.

## What should businesses prepare before cross-border KYB?

**Businesses can shorten their own onboarding by preparing a current registry extract, constitutional documents, a complete ownership chart to the natural persons, identity documents for UBOs and signatories, and a clear description of expected activity and wallets.** Certified translations for non-English documents and a named contact who can answer ownership questions also reduce back-and-forth.

## KryptoGO perspective

KryptoGO provides KYC and KYB, wallet screening, and transaction monitoring for enterprises, payment providers, and VASPs operating across Taiwan and Asia Pacific. Our focus is connecting business verification with the wallets and transactions that follow it, so that onboarding evidence, screening results, and monitoring alerts sit in one auditable workflow.

**Assess your KYB data sources, ownership checks, wallet screening, and exception workflow with the KYB Readiness Checklist.**

*This article is for general information only and does not constitute legal or compliance advice. KYB requirements depend on the firm's regulatory status, the customer's jurisdictions, and the firm's risk assessment.*

## Frequently asked questions

### What is KYB?

KYB (Know Your Business) is the process of verifying a business customer's identity, registration, ownership, control, and risk profile before and during a business relationship. It is part of customer due diligence under anti-money laundering rules.

### Why does KYB take so long?

KYB takes time mainly because entity and ownership data must be verified across sources that use different formats and standards, and because conflicting or incomplete evidence must be resolved by a reviewer. Multi-jurisdiction ownership chains multiply these steps.

### What documents are required for KYB?

Commonly: a registry extract or certificate of incorporation, constitutional documents, a list of directors and authorized signatories, an ownership chart to the natural persons, identity documents for beneficial owners, and information about business activity and source of funds. Requirements vary by provider and jurisdiction.

### What is the difference between KYB and KYC?

KYC verifies an individual. KYB verifies a legal entity and includes KYC on the individuals who own, control, or act for it.

### Can KYB be fully automated?

Not fully in most programs. Data retrieval, extraction, matching, and screening can be automated for many cases, but complex ownership, discrepancies, and higher-risk cases generally require documented human review.

### Why does UBO verification matter?

Beneficial ownership shows who ultimately benefits from or controls a business. Without it, a firm cannot reliably screen for sanctions exposure, conflicts of interest, or the misuse of shell companies.

### Does a business that passes KYB still need wallet screening?

For digital asset flows, generally yes. KYB establishes who the business is; wallet or address screening assesses whether the specific addresses it uses carry sanctions or illicit-activity exposure.

## Sources

- FATF, [*The FATF Recommendations*](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html) (Recommendation 10, Customer Due Diligence; Recommendation 24, Transparency and Beneficial Ownership of Legal Persons).
- FATF, [*Guidance on Beneficial Ownership of Legal Persons*](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-Beneficial-Ownership-Legal-Persons.html), March 2023.
- European Union, [*Regulation (EU) 2024/1624 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing*](https://eur-lex.europa.eu/eli/reg/2024/1624/oj/eng), 31 May 2024.
- FinCEN, [*Beneficial Ownership Information Reporting Requirement Revision*](https://www.federalregister.gov/documents/2026/08/14/2026-16576/beneficial-ownership-information-reporting-requirement-revision), Federal Register, 14 August 2026.
- Fenergo, [*2025 Financial Crime Industry Trends survey*](https://www.fenergo.com/newsroom/global-financial-institutions-struggle-with-rising-client-losses-and-compliance-costs-as-ai-adoption-increases-fenergo), October 2025.
- GLEIF, [*The LEI in Numbers: Q2 2026*](https://www.gleif.org/en/newsroom/blog/the-lei-in-numbers-q2-2026-signals-growing-regional-momentum-for-the-lei), July 2026.

KYB Blog_KryptoGO.png

Cross-border KYB onboarding often stalls on ownership checks and conflicting registry data. Learn which steps teams can automate and which need manual review.

404

Article Not Found!

Or...

Binance Hack: What It Means for Businesses Using Stablecoins

Read More

What Are Maker, Approver, and Signer Roles in an Enterprise Wallet?

Read More

How Should Finance Teams Reconcile Stablecoin Payments at Month End?

Read More

KYB Onboarding: Why Cross-Border Verification Slows Down

Read More