How does Hinkal stay compliant while keeping payments private?
Hinkal stays compliant while keeping payments private by screening every deposit against Chainalysis before it enters a private balance, then re-screening the depositor's address continuously. The customers, vendors and partners you pay cannot see your balances or your other payments on-chain, and you can disclose them to an auditor or regulator with a viewing key or a downloadable transaction history.
By Nika Koreli, Co-founder and CTO. Updated October 2026.
How screening works
Funds sit in a private balance inside the Hinkal smart contract, controlled by the wallet you already use. On-chain, observers see deposits into the contract without attribution to specific operational wallets.
Hinkal checks wallet addresses with Chainalysis when funds enter and every time they move after that. The contract enforces the check on every deposit, private transfer and withdrawal.
1
Screened before entry
Every deposit is screened against Chainalysis before it reaches the private balance. It gets a unique depositId, permanently linked to the wallet address that made it.
2
Proved on every move
To deposit, transfer privately or withdraw, the user generates a zero-knowledge proof that their funds are not associated with any depositId tied to a sanctioned or high-risk address. The contract checks it against the current Chainalysis state, never a snapshot from deposit time.
3
Re-screened continuously
Depositor addresses are re-evaluated automatically as new intelligence, sanctions or risk signals emerge. The compliance status of funds moves with global regulatory datasets, with no reliance on a one-time check at deposit.
The proof reveals nothing about identity, balances or transaction history. For anyone not flagged, privacy stays fully intact.
Receiving through a Hinkal Deposit Address
PSPs, neobanks and businesses paid by customers, exchanges or payment providers can receive through a Hinkal Deposit Address, powered by Hinkal Compliance Gateway. The payer makes a normal on-chain transfer and needs no Hinkal account. Hinkal screens each incoming deposit before it can reach the private balance.
Passes screening
Moves into the private balance automatically, with no extra step for the sender or the recipient.
Does not pass screening
Stays public at the Deposit Address, separate from the private balance. The owner can move it through the public transfer or recovery flow.
Unsolicited or dusting transfer
Screened like any other deposit. If it fails, it stays outside the private balance and separate from screened funds.
Flagged after entry
Loses eligibility for private transfers immediately. The depositor can only withdraw publicly, back to the original address tied to the depositId.
Screening looks at wallet addresses only. For more on checks at the point of entry, read Deposit Address Screening: KYT at the Point of Entry.
Book a demoViewing keys and selective disclosure
Confidential, not anonymous. The account holder controls who sees its activity, and a viewing key is how they share it with an auditor, a regulator or a counterparty.
A viewing key shows balances and incoming transfers. It cannot spend: moving funds always needs separate keys that stay with the wallet owner. Viewing keys are restored from a signature by the wallet you already use, so there is nothing new to store or back up.
Full history
Share every transaction on the account, for an audit or a regulatory request.
A scoped view
Share a specific set of transactions or a time range, and nothing outside it.
The organization master viewing key
Hinkal supports a two-level hierarchy of viewing keys for organizations. Each organization holds a single org master viewing key. Each member's viewing key is derived from it with the Poseidon hash function and a stable member identifier: vk_user = Poseidon(vk_org, user_id).
A member's key decrypts only that member's shielded notes and stealth-address activity. The master key sits one level up, so it can re-derive any member's key and decrypt everything across all members.
It never recovers spending keys. Those stay rooted in each user's wallet signature, on a separate branch of the derivation tree. The organization gets a single credential for compliance, reconciliation and treasury oversight, and that authority is strictly read-only.
Downloadable transaction history and reporting
Viewing keys answer a request. For routine reporting, each Hinkal product keeps a record your team can review or export.
Hinkal Prime
Transaction History is the organization's full record, filterable by network, asset and status. Each entry shows recipient, amount, token, network, public or private source, delivery method and time. Batch payouts are recorded per recipient, so reconciliation works row by row.
Hinkal Wallet
Export transaction history as a CSV file from Settings, for the timeframe you choose. The file covers every transaction type and both public and private account activity.
Hinkal Pay
Viewing keys and downloadable transaction history are available for audit and reporting when required.
Hinkal API and SDK
Viewing keys let authorized parties audit or monitor activity inside your product without making it public.
In Hinkal Prime, a Member can reconcile a payroll cycle without wallet access. Analytics shows how much volume settled privately and how much went out as a direct public transfer. See Hinkal Prime.
What Hinkal does and does not collect
Screening looks at wallet addresses only. Hinkal performs no KYC and needs no personal information to screen or move funds.
What Hinkal works with
Wallet addresses and their Chainalysis screening status. The depositId that links each deposit to the address that made it. For Hinkal Prime teams, Google sign-in, member names and invitation emails, and the organization profile an Owner sets: name, logo and email.
What Hinkal does not hold
KYC data of any kind, for you or for the people you pay. Your keys: in Hinkal Pay, Hinkal never holds your keys and cannot move your funds. Your viewing keys, which your own wallet signature restores.
Customer checks stay with your business. Integrating the Hinkal SDK requires no changes to custody, compliance processes or routing logic, so the checks you run today keep running.
Sanctions handling
Sanctions risk in crypto grew sharply in 2025, and most illicit volume now moves in stablecoins.
Rise in value received by sanctioned entities, 2025
694%
Stablecoins' share of all illicit transaction volume, 2025
84%
Source: Chainalysis, 2026 Crypto Crime Report.
Hinkal handles sanctions with the same proof that runs on every move. Funds tied to a depositId from a sanctioned or high-risk address fail it, and three things follow.
1
No private entry
A flagged wallet cannot move funds into the private balance. Sent to a Hinkal Deposit Address, its transfer stays public at that address, separate from screened funds.
2
No private transfers
If an address is flagged after its funds entered Hinkal, those funds lose eligibility for private transfers immediately.
3
One public exit
The depositor can only withdraw publicly, back to the original address tied to the depositId. That flow is fully traceable and auditable.
No legitimate user's funds are ever commingled with flagged funds. Anything leaving a Hinkal private balance has been checked against the latest compliance data, so exchanges and counterparties can treat it as pre-screened. The aim is that users get privacy without later having their funds or addresses blocked by an exchange, a custodian or another compliance system.
How this maps to the Travel Rule and MiCA
The Travel Rule and MiCA put obligations on the regulated business: the exchange, PSP or crypto-asset service provider. Hinkal gives that business screening, attribution and disclosure that keep working when it moves payments into a private balance.
Jurisdictions with Travel Rule legislation in the FATF's 2026 survey (91 of 109)
83%
EU Travel Rule threshold since December 30, 2024: the same requirements apply to every crypto-asset transfer
No minimum
Above this, an EU provider must assess whether a self-hosted address it sends to or receives from belongs to its own customer
EUR 1,000
Latest end of MiCA's transitional period for providers that operated under national law
July 1, 2026
MiCA has applied in full across the EU since December 30, 2024. Sources: FATF, July 2026 Targeted Update, Regulation (EU) 2023/1113, Regulation (EU) 2023/1114 (MiCA).
What Hinkal gives a regulated business
Screening that keeps running
Every deposit is screened with Chainalysis and re-screened continuously. Funds from sanctioned or high-risk addresses can only leave publicly, to the address they came from.
Attribution for every deposit
Each deposit carries a depositId permanently linked to the wallet address that made it.
Proof of ownership on request
Hinkal Wallet users can export an audit file for a chosen time interval to prove transaction history and ownership, for example in an exchange review. Viewing keys share full or scoped history with an auditor or regulator.
Your compliance stack, unchanged
The Hinkal SDK requires no changes to custody, compliance processes or routing logic. Screening runs on wallet addresses, so your customer data stays in the systems you use today.
A provider that has to check whether a self-hosted address belongs to its customer can ask the account holder for that export or a scoped viewing key. Licensing, customer due diligence and Travel Rule messaging stay with the provider. For a framework-by-framework view, read Confidential Stablecoin Settlement Under MiCA, the Travel Rule, and GENIUS. For the wider data, see On-Chain Transparency and Compliance Statistics 2026.
How compliance differs across privacy approaches
Four ways to move stablecoins, compared on the questions a compliance review asks first: who screens the funds, how an auditor gets the records, and who can see the payments.
Approach
Screening
Disclosure to auditors
Who can see payments
Public wallet
Done by each exchange or provider on its own side, with blockchain analytics. Nothing at the wallet itself.
Nothing to disclose. The auditor reads the public ledger, like everyone else.
Anyone with the address: balances, counterparties, amounts and full history.
Unscreened privacy pool
None in the contract. Any address can deposit.
No built-in tool. Proving one link means revealing the secret behind that deposit.
Deposits and withdrawals are public. The link between them is hidden from everyone, auditors included.
Privacy Pools association sets
An Association Set Provider keeps a set of approved deposits and can revoke approval. Deposits outside the set can only exit publicly, by the original depositor.
A withdrawal proves the deposit is in the approved set.
Deposits and withdrawals are public. The proof hides which deposit funded which withdrawal.
Hinkal
Chainalysis at entry and continuous re-screening, with a depositId on every deposit. Flagged funds can only be withdrawn publicly, to the original address.
Viewing keys for full history, selected transactions or a time range. An org master viewing key across all members. Downloadable transaction history.
The account holder and anyone given a viewing key. A payout to a public address shows the recipient, while the sender and history stay private.
Every model gives something up. A public wallet shows counterparties everything. A pool with no screening hides the link from auditors as well, so there is nothing to show in a review. Privacy Pools ties privacy to a set that someone else curates. Hinkal screens addresses and never people, so customer checks stay with you, and it relies on Chainalysis data: funds flagged after entry lose private transfers even if they passed screening at deposit.
Hinkal never pools funds with other users', and every deposit stays permanently linked to the address that made it. Privacy Pools details come from its documentation. For the last two rows in more depth, read Association Sets vs Selective Disclosure.
FAQ
Who handles KYC when a business uses Hinkal?
The business does. Hinkal screens wallet addresses with Chainalysis and needs no personal information to do it. Integrating the Hinkal SDK requires no changes to your compliance processes, so your existing customer checks keep running.
What happens if a depositor is sanctioned after depositing?
Their funds lose eligibility for private transfers immediately. They can only be withdrawn publicly, back to the original address tied to the depositId, and that flow is fully traceable and auditable.
Can our auditor see our private payments?
Yes, when you share a viewing key. It can cover your full history, a specific set of transactions or a time range. A viewing key is read-only and cannot move funds.
Can a company see all of its team's activity?
Yes. An org master viewing key can re-derive every member's viewing key and decrypt activity across all members. It cannot recover spending keys, so its authority is strictly read-only.
Who handles Travel Rule obligations?
The regulated business that sends or receives the transfer, such as the exchange, PSP or crypto-asset service provider. Hinkal screens wallet addresses, and the Hinkal SDK requires no changes to your existing compliance processes.
What happens to a payment that fails screening at a Deposit Address?
It does not enter the private balance. It stays public at the Deposit Address, separate from screened funds, and the owner can move it through the public transfer or recovery flow.
