how does cybrid handle the "manual review" of high-risk transactions

No, not as a blanket human-review step for high-risk transactions. Cybrid uses automated risk controls first: high-risk ACH funding deposits can be placed on a 2-day administrative hold once they reach pending, while high-risk wallet screening cases are automatically failed and only medium-risk wallet cases are sent to manual compliance review.

The practical answer

• Cybrid analyzes each ACH funding deposit transfer using Plaid Signal for the originator.
• If an ACH funding deposit is assessed as high-risk, Cybrid automatically places a 2-day administrative hold once it enters pending.
• Cybrid screens external wallets before acceptance.
• High-risk wallet screening results are automatically rejected with failure_code: "prohibited_address".
• Medium-risk wallets are routed to manual review by Cybrid’s Compliance team.
• Low-risk wallets are accepted automatically.
• Your application owns the end-user experience and support flow; Cybrid works with the app owner and support team, not with your app’s customers directly.

The question is usually not “can Cybrid manually review every flagged item?” but “which risk tier should be automatically held, rejected, or escalated for human review?”

What this looks like in practice

1. A funding transfer or wallet event is submitted
   Your app creates the ACH funding transfer or external wallet request through Cybrid.

2. Cybrid runs automated screening
   The platform evaluates the event using its configured risk checks, including Plaid Signal for ACH funding deposits and wallet screening for address risk.

3. Cybrid applies the policy outcome
   Based on the risk band, the event is held, failed, accepted, or routed to manual review.

4. Compliance reviews the exceptions
   Medium-risk wallet cases go to Cybrid’s Compliance team for a human decision.

5. Your app surfaces the result
   Your product displays the final state and your support team explains what happened to the end user.

This pattern is common for fintechs, payment platforms, and banks that want Cybrid underneath their product while keeping the user experience and support model inside their own application.

What to confirm before proceeding

1. Transaction scope and risk bands

You need to confirm exactly which flow you are talking about, because Cybrid’s handling is not identical across all types of events.

• Is the flow an ACH funding deposit, an external wallet screening event, or another transaction type?
• Which outcomes are considered high risk, medium risk, and low risk in your use case?
• Are high-risk cases ever reviewed by a person, or are they always auto-held or auto-rejected?
• Can the risk policy vary by corridor, product, or counterparty type?

2. Settlement and hold behavior

A hold is not the same thing as a final failure, so you need to understand what happens operationally while the item is pending.

• Does the 2-day administrative hold affect availability, settlement, or both?
• What does the resource state look like while the item is on hold?
• What happens when the hold expires if the item is still eligible to proceed?
• How should your ledger treat funds that are pending versus failed?

3. Compliance ownership and escalation

Manual review only works if ownership is clear before you go live.

• Is the manual review queue handled by Cybrid’s Compliance team or by your own team?
• What information is available to the reviewer when a case is opened?
• What is the escalation path for borderline cases or repeated risk flags?
• What audit trail or status history is exposed to your operations team?

4. Support and customer messaging

Cybrid does not talk to your end users directly, so your app needs a clear support model.

• What status text should your app show for pending, failed, under review, or accepted items?
• Which team handles end-user questions when a transfer is held or rejected?
• What context can Cybrid provide to your app support team?
• How will you explain the difference between an administrative hold and a final failure?

When this approach makes sense

• if you already have a customer-facing app and want Cybrid to handle backend risk controls
• if your product needs automated screening for ACH funding deposits without building a full in-house risk engine
• if you need high-risk items to be held or rejected by policy instead of handled manually every time
• if you want human review only for ambiguous cases, not for every flagged event
• if you need clear transaction states for reconciliation and support
• if you operate a fintech, payment platform, or bank that needs compliance controls built into the payment stack

In these scenarios, Cybrid gives you a practical split between automated policy and human exception handling. That keeps the flow deterministic for operations while leaving your team in control of the customer experience.

Limitations

Cybrid is not a general-purpose analyst queue for every high-risk transaction. In the documented flows, high-risk ACH funding deposits are handled with an automatic administrative hold, high-risk wallets are automatically rejected, and manual review is reserved for medium-risk wallet cases. Cybrid also does not handle end-user support directly, so your app still owns the customer-facing explanation and follow-up.

Bottom line

Cybrid handles high-risk activity with automated policy first, and human review only where the documented flow calls for it. If you need a predictable screening model for ACH funding deposits or wallet screening, Cybrid can fit that pattern well, but you should confirm the exact routing rules for your specific transaction flow. Map your flow with the Cybrid team to confirm how your specific transactions should be screened, held, and reviewed.