Fraud Detection
Network-based fraud intelligence that catches patterns invisible to rule engines and isolated entity analysis.
Beyond Rules and Attributes
Traditional fraud detection relies on rules and isolated entity analysis. It catches known patterns but misses the sophisticated schemes that exploit network relationships.
Fraud is a network problem. A company might look clean in isolation, but its connections reveal the truth: shared addresses with known bad actors, ownership links to shell entities, suppliers with suspicious patterns.
How Avra Detects Fraud
Entity Intelligence
Registration anomalies, address inconsistencies, ownership patterns, activity mismatches
Network Analysis
Multi-hop relationships: counterparties, suppliers, ownership chains, shared infrastructure
Behavioral Patterns
Transaction velocity, payment patterns, seasonal variations—compared against similar legitimate entities
Temporal Dynamics
How is this entity evolving? Rapid changes in network position often signal fraud or distress
What We Catch
| Signal Type | What Traditional Systems See | What Avra Sees |
|---|---|---|
| Shell entities | Clean registration, no red flags | Multi-hop connections to known bad actors |
| Identity fraud | Valid documents, matching records | Ownership network anomalies, address clustering |
| Bust-out schemes | Good payment history building | Trajectory toward known fraud patterns |
| Collusion rings | Unrelated legitimate entities | Hidden network connections, coordinated behavior |
Use Cases
Onboarding Verification
Screen new counterparties before establishing relationships
Transaction Monitoring
Real-time risk signals for payment authorization
Portfolio Screening
Periodic review of existing relationships for emerging risks
Investigation Support
Deep network analysis when suspicious activity is detected
Powered by two foundations
Fraud detection is where Avra’s network intelligence is most direct. The Graph Foundation Model has learned what legitimate and suspicious network structures look like across the broader economy. Your Relational Foundation Model has learned the shape of your own transactions, customers, and accounts. The downstream fraud model is trained on top of both — and every training run feeds signal back into your RFM, making the next iteration sharper.
Customer Data Needed
| Data | Purpose |
|---|---|
| Fraud labels | Historical confirmed fraud and legitimate cases to define your fraud definition |
| Transaction history | Payment patterns, amounts, and counterparty details |
| Application data | Onboarding information for registration-time scoring |
Output Schema
| Field | Description |
|---|---|
fraud_score |
Probability (0-1) that the entity or transaction is fraudulent |
risk_factors |
Key signals contributing to the score (network anomalies, velocity, entity attributes) |
network_flags |
Specific multi-hop connections to known bad actors or suspicious clusters |
Evaluation Metrics
- PR-AUC — Primary metric, given the rarity of fraud events. Measures precision-recall trade-off across all thresholds.
- ROC-AUC — Overall discrimination between fraud and legitimate activity.
- False Positive Rate at fixed recall — Operational metric: how many legitimate entities are flagged at your desired catch rate.
Multi-resolution embeddings for fraud
Avra’s adaptive embeddings enable multi-resolution fraud architectures:
- Transaction-level (64–128d) — lightweight embeddings for real-time transaction scoring where latency is critical. Fast enough to run on every payment.
- Entity-level (512–1024d) — full-resolution embeddings for deep entity analysis. Rich context about the entity including network position, ownership patterns, and behavioral history.
This allows your fraud model to combine quick transaction signals with deep entity intelligence—smaller embeddings provide speed, larger embeddings provide context.