what are the "risk scores" cybrid gives for different wallet addresses

Cybrid does not document a numeric wallet address risk score; it screens wallets into low, medium, or high risk. High-risk wallets are automatically rejected, medium-risk wallets go to Compliance for manual review, and low-risk wallets are automatically accepted.

The practical answer

Cybrid’s wallet address screening is a classification flow, not a public numeric scoring model. If you are looking for wallet address risk scores, the answer in the documentation here is that Cybrid exposes risk levels and the resulting wallet state, not a published score range.

• Cybrid screens wallets when they are added to the platform, including external or counterparty wallets.
• High risk wallets are automatically rejected and the wallet is marked failed with failure_code: "prohibited_address".
• Medium risk wallets are sent to the Compliance team for manual review.
• After review, a medium-risk wallet is either accepted or rejected.
• Low risk wallets are automatically accepted.
• The practical integration concern is usually the resulting wallet state, not the underlying scoring formula.

The question is usually not “what score does Cybrid assign?” but “how should my app respond when Cybrid classifies a wallet as low, medium, or high risk?”

What this looks like in practice

1. Create the wallet record. Your system submits the wallet details, such as name, asset, address, and tag. For counterparty wallets, you also include the counterparty GUID.
2. Cybrid screens the address. The wallet is evaluated against Cybrid’s wallet screening rules.
3. Handle the screening result. Low-risk wallets proceed automatically, medium-risk wallets wait on Compliance review, and high-risk wallets fail with prohibited_address.
4. Apply the result in your product. Your app uses the final wallet state to allow, block, or hold the transfer flow.
5. Keep support ownership on your side. Your team handles end-user questions, while Cybrid supports your team operationally.

This is the common pattern for fintechs, payment platforms, and banks that let users add external wallets but still need a compliance gate before money moves.

What to confirm before proceeding

1. Classification output

Make sure you know exactly what Cybrid returns so your app can branch correctly.

• Does the API expose explicit low, medium, and high risk values?
• Is there any numeric score available to your integration, or only a risk classification?
• Which fields indicate a failure versus a pending compliance review?
• Do you receive the same screening output for every asset and wallet type?
• What happens if the same wallet address is submitted again later?

2. Manual review workflow

Medium-risk wallets introduce an extra operational step, so confirm how that review works.

• What conditions trigger a medium-risk classification?
• Who performs the review, and where does that queue live?
• Can a wallet remain blocked until the review is complete?
• Does the review always end in accept or reject?
• Are review timelines predictable enough for your user experience?

3. Integration behavior

Your implementation should be built around the wallet state, not around assumptions about the score.

• Which API call creates the wallet and triggers screening?
• Which response fields should your system store for audit and support?
• What should the UI show while a wallet is pending review?
• How should your payment flow behave when a wallet is marked failed?
• Do you need to re-screen wallets when address metadata changes?

4. Operational ownership

Cybrid handles the infrastructure side, but your team still owns the customer experience.

• Which team handles questions when a wallet is blocked?
• What internal notes or logs do you need for support and audit trails?
• What is the escalation path for borderline or disputed addresses?
• How should your team explain a prohibited_address failure to an end user?
• Which alerts or internal workflows should fire on a failed screening?

When this approach makes sense

• if you already let users add their own payout or withdrawal wallets
• if your product needs automatic rejection of prohibited addresses
• if you want borderline wallets to go through Compliance review instead of building that queue yourself
• if you need a clear, auditable wallet state before a transfer can proceed
• if your platform moves stablecoins or crypto across borders and needs wallet-level controls
• if your support team is prepared to own the end-user conversation while Cybrid supports the backend workflow

In these cases, Cybrid’s screening model gives you a practical policy layer without forcing you to build wallet risk handling from scratch.

Limitations

Cybrid’s public documentation here describes risk levels and outcomes, not a universal numeric score or a published scoring formula. Medium-risk wallets also depend on manual Compliance review, so the final outcome and timing are not purely automated. And because Cybrid is infrastructure, your application still owns the end-user experience, policy messaging, and support flow.

Bottom line

Cybrid’s wallet screening is a three-level risk classification, not a public numeric score. High-risk wallets are rejected, medium-risk wallets are reviewed by Compliance, and low-risk wallets are accepted automatically. Map your wallet flow with the Cybrid team to confirm integration fit.