Home Protocol Security Compliance Anti-Fraud AML Whitepaper ghostpaymesh.com

Anti-Fraud System

Multi-layered fraud prevention architecture — device fingerprinting, risk scoring, double-spend prevention, chain integrity verification, and automated threat detection.

1. Overview

GhostPay Mesh implements a defense-in-depth anti-fraud architecture that operates across both offline and online environments. The system combines cryptographic guarantees (inherent to the PLC protocol) with behavioral analysis, device intelligence, and real-time risk scoring.

The anti-fraud system is designed around three core principles:

  • Prevention First — block fraudulent transactions before they execute, not after
  • Graceful Degradation — fraud checks work offline with local heuristics and reconcile server-side when connectivity returns
  • Minimal False Positives — the risk engine is calibrated to avoid blocking legitimate users while catching real threats
graph TB
    TX[Incoming Transaction] --> DF[Device Fingerprint Check]
    DF --> RS[Risk Score Engine]
    RS --> RL[Rate Limiter]
    RL --> DS[Double-Spend Check]
    DS --> CI[Chain Integrity Verify]
    CI -->|Pass| APPROVE[Transaction Approved]
    CI -->|Fail| BLOCK[Transaction Blocked]
    DF -->|Device Blocked| BLOCK
    RS -->|High Risk| REVIEW[Manual Review Queue]
    RL -->|Limit Exceeded| BLOCK
    DS -->|Double Spend| BLOCK

2. Device Fingerprinting

Every device in the GhostPay Mesh network generates a unique, hardware-derived fingerprint that serves as a pseudonymous identifier. This fingerprint is used to track device behavior without collecting personal data.

Fingerprint Components

Component Source Stability Purpose
Hardware ID Secure Enclave / TEE Permanent Root device identity
Key Attestation Ed25519 key pair Permanent Cryptographic binding
OS Fingerprint OS version + build Semi-stable Environment validation
App Integrity Code signature hash Per-version Tamper detection
Behavioral Hash Usage patterns Dynamic Anomaly detection

Fingerprint Generation

Device Fingerprint Structure
{
  "device_fingerprint": {
    "hardware_id": "sha256:a1b2c3d4e5f6...",
    "key_attestation": "ed25519:9f8e7d6c5b4a...",
    "os_fingerprint": "sha256:1a2b3c4d...",
    "app_integrity": "sha256:f0e1d2c3...",
    "composite_hash": "sha256:final_composite...",
    "generated_at": "2025-01-15T10:30:00Z"
  }
}

Device Reputation System

Each device accumulates a reputation score based on its transaction history. New devices start at a neutral score and build reputation through legitimate activity:

  • Score 0–30 (Untrusted): New or flagged devices. Strict limits, enhanced monitoring.
  • Score 31–60 (Normal): Devices with some transaction history. Standard limits apply.
  • Score 61–85 (Trusted): Established devices with clean history. Relaxed velocity checks.
  • Score 86–100 (Verified): Long-standing devices with Tier 2 KYC. Highest limits available.
Privacy Note: Device fingerprints are stored as one-way hashes. The original hardware identifiers cannot be reconstructed from the fingerprint. No personal data is included.

3. Risk Flags

The risk scoring engine evaluates every transaction against a set of configurable risk flags. Each flag contributes a weighted score to the overall risk assessment:

Flag Category Weight Trigger Condition
VELOCITY_HIGH Behavioral 0.35 > 10 PLCs issued in 30 minutes
AMOUNT_ANOMALY Financial 0.40 PLC amount > 3σ from device average
DEVICE_BLOCKED Device 1.00 Device on global blocklist
GEO_IMPOSSIBLE Location 0.60 Transaction from impossible location change
CHAIN_DEPTH_HIGH Protocol 0.25 Transfer chain > 7 hops
NEW_DEVICE Device 0.15 Device registered < 24 hours ago
CLOCK_DRIFT Integrity 0.30 Device clock diverges > 15 min from network
SIGNATURE_REUSE Cryptographic 0.90 Same nonce or signature seen before

Risk Score Calculation

The composite risk score is computed as a weighted sum of active flags, normalized to a 0–100 scale:

Risk Score Formula
// Risk score computation
risk_score = min(100, sum(flag.weight * 100 for flag in active_flags))

// Decision thresholds
APPROVE  = risk_score < 40
REVIEW   = 40 <= risk_score < 70
BLOCK    = risk_score >= 70
Offline Mode: When operating offline, devices use a simplified local risk engine with cached flag rules. Full risk scoring is performed upon reconnection.

4. Double-Spend Prevention

Double-spending is the primary fraud vector in any digital payment system. GhostPay Mesh prevents double-spending through a combination of cryptographic chain hashing and server-side deduplication.

Chain Hash Mechanism

Every transfer in the transfer_chain includes a hash of the previous transfer entry, creating an immutable linked list:

graph LR
    A["Transfer 0
hash: H0 = SHA256(issuer_sig)"] --> B["Transfer 1
hash: H1 = SHA256(H0 + sig1)"]
    B --> C["Transfer 2
hash: H2 = SHA256(H1 + sig2)"]
    C --> D["Transfer 3
hash: H3 = SHA256(H2 + sig3)"]

    style A fill:#1a1a2e,stroke:#A855F7,color:#e4e4e7
    style B fill:#1a1a2e,stroke:#A855F7,color:#e4e4e7
    style C fill:#1a1a2e,stroke:#A855F7,color:#e4e4e7
    style D fill:#1a1a2e,stroke:#A855F7,color:#e4e4e7

Fork Detection

If an attacker attempts to create two different transfers from the same PLC state (a “fork”), the server detects the conflict during settlement:

  1. Two settlement requests arrive with the same plc_id but different transfer_chain histories
  2. The server identifies the fork point — the last common chain entry
  3. Both forks are rejected. The PLC is frozen pending investigation.
  4. The device that initiated the fork is flagged with DEVICE_BLOCKED

Offline Double-Spend Mitigation

In fully offline scenarios, double-spending cannot be prevented in real-time. Instead, the protocol uses economic deterrents:

  • PLCs have a maximum offline transfer limit (10 hops) to constrain the blast radius
  • Per-PLC value limits (R$ 1,000) cap the maximum loss per double-spend
  • Device reputation scores drop dramatically upon detection, blocking future transactions
  • Repeat offenders are added to a distributed blocklist propagated via mesh gossip
Critical: Devices that attempt double-spending are permanently blocklisted across the mesh network. The blocklist is cryptographically signed and propagated via BLE gossip protocol.

5. Transfer Chain Integrity Verification

Every PLC carries a self-verifiable transfer chain that can be validated by any device without server access. The verification process ensures the chain has not been tampered with, truncated, or forked.

Verification Algorithm

Chain Verification (Pseudocode)
function verify_chain(plc):
  // 1. Verify issuer signature on commitment_hash
  assert ed25519_verify(plc.issuer_pubkey, plc.commitment_hash, plc.signature)

  // 2. Verify commitment_hash integrity
  expected_hash = SHA256(plc.id + plc.amount + plc.currency
                 + plc.issuer_pubkey + plc.created_at
                 + plc.expires_at + plc.nonce)
  assert expected_hash == plc.commitment_hash

  // 3. Walk the transfer chain
  prev_hash = SHA256(plc.signature)
  expected_holder = plc.issuer_pubkey

  for transfer in plc.transfer_chain:
    assert transfer.from_pubkey == expected_holder
    payload = transfer.to_pubkey + transfer.timestamp
            + transfer.nonce + prev_hash
    assert ed25519_verify(transfer.from_pubkey, payload, transfer.signature)
    prev_hash = SHA256(transfer.signature)
    expected_holder = transfer.to_pubkey

  return true

Integrity Checks Summary

Check Detects Offline?
Commitment hash recalculation Field tampering (amount, expiry, etc.) Yes
Issuer signature verification Forged PLCs Yes
Chain link hash verification Truncation, reordering, insertion Yes
Transfer signature verification Unauthorized transfers, chain forking Yes
Nonce uniqueness check Replay attacks Local cache
Expiration check Expired PLC usage Yes (clock tolerant)

6. Circuit Breaker for External APIs

GhostPay Mesh integrates with external services (Pix, BACEN, identity providers). The circuit breaker pattern prevents cascading failures when these services are unavailable or degraded.

Circuit Breaker States

stateDiagram-v2
    [*] --> CLOSED : Normal operation
    CLOSED --> OPEN : Failure threshold reached
    OPEN --> HALF_OPEN : Timeout expires
    HALF_OPEN --> CLOSED : Probe succeeds
    HALF_OPEN --> OPEN : Probe fails
State Behavior Transition
CLOSED Normal operation. Requests pass through. Failures are counted. Opens after 5 consecutive failures or >50% failure rate in 60s window
OPEN All requests to the service are rejected immediately. Fallback behavior activated. Transitions to HALF_OPEN after configurable timeout (default: 30s)
HALF_OPEN A single probe request is sent. If it succeeds, circuit closes. If it fails, circuit reopens. CLOSED on success, OPEN on failure

Per-Service Configuration

Circuit Breaker Config
{
  "circuit_breakers": {
    "pix_settlement": {
      "failure_threshold": 5,
      "recovery_timeout_ms": 30000,
      "monitoring_window_ms": 60000,
      "fallback": "queue_for_retry"
    },
    "bacen_api": {
      "failure_threshold": 3,
      "recovery_timeout_ms": 60000,
      "monitoring_window_ms": 120000,
      "fallback": "use_cached_data"
    },
    "identity_provider": {
      "failure_threshold": 3,
      "recovery_timeout_ms": 45000,
      "monitoring_window_ms": 90000,
      "fallback": "defer_verification"
    }
  }
}

7. Rate Limiting

Rate limiting is applied at multiple granularities to prevent abuse and ensure fair resource allocation:

Scope Algorithm Limit Window
Per device (API) Token bucket 60 req/min Sliding 1 min
Per device (PLC issuance) Fixed window 20 PLCs/hour Fixed 1 hour
Per device (settlement) Token bucket 10 settlements/hour Sliding 1 hour
Per IP (API) Sliding window log 300 req/min Sliding 1 min
Global (settlements) Token bucket 10,000/min Sliding 1 min

Rate Limit Response

429 Too Many Requests
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1705312800
Retry-After: 23

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests. Please retry after 23 seconds.",
  "retry_after": 23
}

8. Automated Fraud Detection

The automated fraud detection engine runs continuously, analyzing transaction patterns across the entire mesh network. It combines rule-based detection with statistical anomaly detection.

Detection Rules Engine

The rules engine evaluates configurable conditions in real-time:

  • Structuring Detection: Multiple PLCs just below reporting thresholds (e.g., 5 PLCs of R$ 990 instead of 1 PLC of R$ 4,950)
  • Round-Trip Detection: PLCs transferred in a circle back to the original issuer (potential wash trading)
  • Burst Pattern: Sudden spike in PLC issuance from a previously dormant device
  • Identical Amount Clustering: Multiple PLCs with the exact same amount from different devices in a short window
  • Time-Zone Anomaly: Transactions submitted at unusual hours for the device’s established timezone pattern

Anomaly Detection Pipeline

graph LR
    A[Transaction Stream] --> B[Feature Extraction]
    B --> C[Statistical Model]
    C --> D{Anomaly Score}
    D -->|Normal| E[Log & Pass]
    D -->|Suspicious| F[Alert Queue]
    D -->|Critical| G[Auto-Block]
    F --> H[Analyst Review]
    H -->|Legitimate| I[Release + Learn]
    H -->|Fraud| J[Block + Report]

Alert Severity Levels

Level Score Range Response Time Action
LOW 40–55 24 hours Log + enhanced monitoring
MEDIUM 55–70 4 hours Analyst review queue
HIGH 70–85 30 minutes Temporary device restriction
CRITICAL 85–100 Immediate Auto-block + COAF notification
Continuous Learning: The anomaly detection model is updated weekly with new patterns from confirmed fraud cases. False positive feedback from analyst reviews is incorporated to reduce noise.