Deployment & Integration
Shadow first, then inline; pilot first, then scale
Never experiment on production traffic. Shadow mode captures real distributions, high-confidence rules go inline first, and pilots verify user outreach — every stage has explicit exit criteria.
Delivery methodology
A four-phase delivery path
Click any phase to see actions and exit criteria; step through left and right.
Key actions
- Question-set & fusion rule design
- Synthetic/public sample validation
- 1,000-item human evaluation
- Judgment quality report
Exit criteria
- Per-type recall meets bar
- Zero hard-negative false kills
- Latency budget confirmed
Engineering guardrails
An anti-fraud system must not create new risk
Every deployment form follows the same guardrails — a precondition for all phases, not an optional configuration.
On model or service failure, traffic bypasses — never block normal business because of an anti-fraud component.
New models mirror real traffic first, record-only, before entering the disposition path.
Gray rollout by port/region/traffic share; anomalous metrics trigger automatic circuit breaks and rollback.
Every disposition action carries evidence; users can appeal; policies roll back by version.
Inline gateway paths are rate-limited; overload degrades to the rule layer.
Compliance & security
Compliance is a design premise, not a patch
The stronger the anti-fraud capability, the clearer the boundary of what can be seen, stored, done — and not done.
Five principles
Three red lines
- No written authorization: no ingestion, no delivery
- No defined purpose: no sharing
- No audit trail: no high-privilege export
Channel boundaries
A2P / 国际Under the contract & filing framework, signature, template, and link governance are statutory duties; the content model is used only for fraud anomaly leads.
P2PWithin the secrecy boundary — the network side sees only metadata; the device side sees content, and raw text is never uploaded or centrally stored.
What we do not do
- Store full communication content
- Provide raw content to third parties
- Use data for non-anti-fraud purposes
- Perform full content checks on P2P traffic
- Review commercial SMS content in the name of anti-fraud
Integration forms
Four deployment forms with explicit status
Implemented and planned capabilities labeled item by item — roadmaps are not written as current state.
Cloud API / batch service
Real batch runBatch runs are validated (TG 58,133 groups); the external intelligence API is planned — the first domain/IP risk-score capabilities are ready.
- Batch run service (delivered)
- Intelligence API (planned)
- De-identified upload
On-premise deployment
Capability readyThe model and inference service deploy into customer intranets (carriers/banks/police); data never leaves the domain, staged online per the delivery methodology.
- Intranet inference service
- Data never leaves the domain
- Integration with existing platforms
Gateway inline embedding
Pilot validationValidated in the SMS gateway demo environment: 82ms judgment-to-alert with fail-open protection. Formal inline follows the Phase 2 path.
- SMS entry inline (pilot scope)
- Mostly metadata
- fail-open protection
On-device SDK
Pilot validationThe on-device form is in demo validation: <50ms per line, content never leaves the device. Small/quantized versions adapt per device model.
- On-device inference (demo metric)
- Content stays on device
- Device adaptation in evaluation
Intelligence API example (design draft)
POST /v1/risk/domain
{ "domain": "xx-protect-close.com" }{
"score": 0.97,
"type": "impersonation_platform",
"signals": ["domain_age_2d", "no_icp", "blacklist", "asks_user_click"],
"action": "block"
}The interface is a design draft; the first capabilities cover domain / IP risk scores, with app and card capabilities expanding per plan.
Start with one offline validation
We offer a 2–4 week Phase 0: pick a scenario, authorize samples, and receive a human-evaluated quality report.