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

Anti-Fraud System

Institutional overview of fraud prevention controls. Internal methodology, parameters, and decision rules are not published.

1. Overview

GhostPay Mesh applies proprietary, defense-in-depth fraud controls across offline and online operation. Controls combine cryptographic guarantees inherent to the PLC protocol with operational monitoring and reconciliation when connectivity is restored.

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 — controls are calibrated to avoid blocking legitimate users while catching real threats
Risk Controls: GhostPayMesh uses proprietary risk controls to evaluate technical and operational signals, apply dynamic limits, and support secure reconciliation after connectivity is restored. Internal methodology, parameters, and decision rules are not published.

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 asymmetric 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 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:

  • Untrusted Device: New or flagged devices. Strict limits, enhanced monitoring.
  • Normal Device: Devices with some transaction history. Standard operational limits apply.
  • Trusted tier: Established devices with clean history. Elevated transaction capacity applies per operational parameters.
  • Verified Device: 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 Controls

GhostPayMesh uses proprietary risk controls to evaluate technical and operational signals, apply dynamic limits, and support secure reconciliation after connectivity is restored. Internal methodology, parameters, and decision rules are not published.

Offline Mode: When operating offline, devices apply simplified local controls. Full reconciliation 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 an offline transfer limit (enforced by protocol) 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 mesh propagation 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)
// Chain verification algorithm — implementation details in partner documentation.
// Steps: issuer signature verification → commitment integrity → transfer chain validation
// Full pseudocode available to registered integration partners.

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 parameters (failure thresholds, recovery timeouts, monitoring windows and fallback behaviors) are internal operational settings. Per-service configuration is available in partner documentation.

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 rate-limited per device Sliding 1 min
Per device (PLC issuance) Fixed window PLC issuance rate-limited 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.