# Fraud Detection and Data Leak Prevention Roadmap

This roadmap is for:

- `Fraud detection`
- `Data leak prevention (DLP)`

If you also want the separate `data lake` roadmap, that is already documented in:

- [FRAUD_DETECTION_AND_DATA_LAKE_ROADMAP.md](/var/www/php84/sms_admin_es/docs/FRAUD_DETECTION_AND_DATA_LAKE_ROADMAP.md)

## 1. What you already have in this system

These are useful building blocks already present in the repo.

### Security, audit, and tenancy foundations

- Request audit capture middleware:
  - [app/Http/Middleware/CaptureAuditEvent.php](/var/www/php84/sms_admin_es/app/Http/Middleware/CaptureAuditEvent.php)
- Async audit publishing:
  - [app/Services/Audit/AuditEventPublisher.php](/var/www/php84/sms_admin_es/app/Services/Audit/AuditEventPublisher.php)
  - [app/Jobs/ProcessAuditLogJob.php](/var/www/php84/sms_admin_es/app/Jobs/ProcessAuditLogJob.php)
- Audit payload redaction support:
  - [config/audit.php](/var/www/php84/sms_admin_es/config/audit.php)
  - [app/Services/Audit/AuditEventFactory.php](/var/www/php84/sms_admin_es/app/Services/Audit/AuditEventFactory.php)
- Tenant scoping / app isolation helpers:
  - [app/Services/AppIdEncryptionService.php](/var/www/php84/sms_admin_es/app/Services/AppIdEncryptionService.php)
- Existing audit architecture notes:
  - [docs/enterprise-audit-logging.md](/var/www/php84/sms_admin_es/docs/enterprise-audit-logging.md)

### Analytics and risk foundations

- ClickHouse-backed analytics services:
  - [app/Services/Churn/ChurnClickhouseService.php](/var/www/php84/sms_admin_es/app/Services/Churn/ChurnClickhouseService.php)
  - [app/Services/Subscriber360/SubscriberJourneyClickhouseService.php](/var/www/php84/sms_admin_es/app/Services/Subscriber360/SubscriberJourneyClickhouseService.php)
  - [app/Services/Audit/AuditClickhouseService.php](/var/www/php84/sms_admin_es/app/Services/Audit/AuditClickhouseService.php)
  - [app/Services/Support/SupportDeskClickhouseService.php](/var/www/php84/sms_admin_es/app/Services/Support/SupportDeskClickhouseService.php)
- Existing risk/admin surface:
  - [app/Filament/Pages/RiskManagement/RiskManagement.php](/var/www/php84/sms_admin_es/app/Filament/Pages/RiskManagement/RiskManagement.php)
- Existing ML pattern you can reuse:
  - `ml/`
  - [app/Services/AiChurnDataService.php](/var/www/php84/sms_admin_es/app/Services/AiChurnDataService.php)

### Operational signals that can feed fraud/DLP

- SMS delivery callback entry point:
  - [app/Http/Controllers/Sms/SmsDeliveryCallbackController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Sms/SmsDeliveryCallbackController.php)
- Bulk messaging jobs:
  - [app/Jobs/SendBulkSmsJob.php](/var/www/php84/sms_admin_es/app/Jobs/SendBulkSmsJob.php)
- SMS dispatch state tracking:
  - [app/Services/Sms/SmsDispatchTracker.php](/var/www/php84/sms_admin_es/app/Services/Sms/SmsDispatchTracker.php)
- Billing / refund / subscription flows:
  - [app/Http/Controllers/UserAdminActionController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/UserAdminActionController.php)
  - [app/Http/Controllers/Subscription/SubscriptionUpgradeController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Subscription/SubscriptionUpgradeController.php)
  - [app/Services/Subscription/SubscriptionUpgradeService.php](/var/www/php84/sms_admin_es/app/Services/Subscription/SubscriptionUpgradeService.php)

### Logging / monitoring

- GCP log query service:
  - [app/Services/Logs/GcpLoggingService.php](/var/www/php84/sms_admin_es/app/Services/Logs/GcpLoggingService.php)
- Data freshness and gateway monitoring:
  - [app/Services/Monitoring/DataFreshnessMonitorService.php](/var/www/php84/sms_admin_es/app/Services/Monitoring/DataFreshnessMonitorService.php)
  - [app/Services/Billing/GatewayHealthMonitorService.php](/var/www/php84/sms_admin_es/app/Services/Billing/GatewayHealthMonitorService.php)

## 2. Biggest gaps today

### Fraud detection gaps

- No dedicated `fraud_events` stream yet
- No `fraud_rules`, `fraud_decisions`, or `fraud_cases` tables
- No rule engine for velocity, promo abuse, refund abuse, or account takeover
- No analyst review console for fraud triage
- No fraud feature store or fraud model scoring pipeline
- No step-up actions such as challenge, temporary hold, or analyst review queue

### Data leak prevention gaps

- Export/download routes in [routes/web.php](/var/www/php84/sms_admin_es/routes/web.php) do not show explicit auth/authorization middleware like surrounding admin routes
- Export download actions currently fetch files by numeric id and return them without visible ownership / `app_id` checks in:
  - [app/Http/Controllers/Customer/UserExportController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Customer/UserExportController.php)
  - [app/Http/Controllers/Dashboard/DashboardExportController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Dashboard/DashboardExportController.php)
  - [app/Http/Controllers/Billing/BillingExportController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Billing/BillingExportController.php)
  - [app/Http/Controllers/Ticket/TicketExportController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Ticket/TicketExportController.php)
- Export files are being stored under `storage/app/exports` in several flows, which is fine operationally, but there is no consistent DLP policy around retention, masking, approval, watermarking, or expiry
- Audit redaction exists, but export payload masking is not centralized
- No dataset classification such as `public`, `internal`, `restricted`, `PII`
- No anomaly detection for unusual download volume, cross-tenant access, bulk CSV generation, or off-hours export activity
- No centralized incident workflow for suspicious data access

## 3. Recommended target architecture

Build this in 2 parallel tracks.

### A. Fraud detection track

1. `Signal collection`
2. `Rules + scoring`
3. `Case management`
4. `Enforcement`

### B. DLP track

1. `Data classification`
2. `Access control + authorization`
3. `Masking + secure export`
4. `Detection + alerting`
5. `Incident response`

## 4. Fraud detection roadmap

### Phase 1: Create a fraud event backbone

Add these first.

#### PostgreSQL

- `fraud_rules`
- `fraud_rule_versions`
- `fraud_decisions`
- `fraud_cases`
- `fraud_case_notes`
- `fraud_allowlist`
- `fraud_blocklist`
- `fraud_review_feedback`

#### ClickHouse

- `fraud_events`
- `fraud_signals`
- `fraud_feature_store`
- `fraud_model_scores`

Recommended `fraud_events` fields:

- `event_id`
- `event_time`
- `app_id`
- `event_type`
- `customer_id`
- `sms_cust_id`
- `order_id`
- `subscription_id`
- `transaction_id`
- `payment_gateway`
- `ip_address`
- `device_id`
- `country`
- `platform`
- `amount`
- `currency`
- `coupon_code`
- `status`
- `source_module`
- `raw_payload`

### Phase 2: Publish fraud signals from real flows

Start as passive side-effects only. Do not block the current workflow.

Add publishers around:

- login failures
- OTP send / verify failures
- refund initiation / refund success / refund failure
- repeated subscription upgrades
- repeated coupon or voucher attempts
- bulk SMS dispatch spikes
- delivery callback anomalies
- support-ticket bursts

Best hook points in this repo:

- [app/Http/Controllers/UserAdminActionController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/UserAdminActionController.php)
- [app/Http/Controllers/Subscription/SubscriptionUpgradeController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Subscription/SubscriptionUpgradeController.php)
- [app/Services/Subscription/SubscriptionUpgradeService.php](/var/www/php84/sms_admin_es/app/Services/Subscription/SubscriptionUpgradeService.php)
- [app/Http/Controllers/Sms/SmsDeliveryCallbackController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Sms/SmsDeliveryCallbackController.php)
- [app/Jobs/SendBulkSmsJob.php](/var/www/php84/sms_admin_es/app/Jobs/SendBulkSmsJob.php)

Implementation note:

- create `App\Services\Fraud\FraudEventPublisher`
- keep the same pattern as the audit publisher: queue it, do not break the primary action on fraud-log failure

### Phase 3: Ship rule-based scoring first

Start with deterministic rules.

Recommended first rules:

#### Auth / account abuse

- too many failed logins in 10 minutes
- too many OTP sends to one number in 15 minutes
- too many OTP verifies from same IP or device
- login from new geo + payment attempt shortly after

#### Payment / refund abuse

- too many failed payments in rolling 1 hour
- repeated refund requests for same customer or payment instrument
- refund right after activation or upgrade
- same payment identity reused across multiple accounts

#### Promo abuse

- same coupon used across too many accounts
- same device/IP claiming multiple intro offers
- repeated invalid coupon retries

#### Messaging abuse

- sudden bulk SMS spike from one tenant/user
- very high failure ratio by template/provider
- repeated retry storms from same campaign

### Phase 4: Add fraud operations UI

Extend the existing risk area with:

- `Fraud Alerts`
- `Fraud Cases`
- `Rules & Thresholds`
- `Allowlist / Blocklist`
- `Analyst Review`
- `Fraud Analytics`

Best starting place:

- [app/Filament/Pages/RiskManagement/RiskManagement.php](/var/www/php84/sms_admin_es/app/Filament/Pages/RiskManagement/RiskManagement.php)

### Phase 5: Add ML scoring only after labels exist

Reuse the churn ML pattern once you have:

- 60 to 90 days of fraud events
- analyst feedback
- true-positive / false-positive labels

Suggested first fraud features:

- `failed_login_count_10m`
- `otp_send_count_15m`
- `distinct_devices_24h`
- `payment_fail_count_1h`
- `refund_count_30d`
- `coupon_attempt_count_24h`
- `bulk_sms_count_1h`
- `delivery_failure_ratio_1h`

## 5. Data leak prevention roadmap

### Phase 1: Close the obvious access gaps first

This is the highest priority.

#### A. Protect export routes

Apply explicit middleware to export routes in:

- [routes/web.php](/var/www/php84/sms_admin_es/routes/web.php)

Recommended minimum:

- `auth`
- `web`
- `throttle`
- permission / module-access middleware if available

#### B. Enforce ownership and tenant checks on download

For every `downloadExport($id)`:

- verify current user can access the record
- verify `saved_dashboards.app_id` matches current tenant
- verify creator or privileged role
- reject cross-tenant id guessing

Controllers to harden first:

- [app/Http/Controllers/Customer/UserExportController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Customer/UserExportController.php)
- [app/Http/Controllers/Dashboard/DashboardExportController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Dashboard/DashboardExportController.php)
- [app/Http/Controllers/Billing/BillingExportController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Billing/BillingExportController.php)
- [app/Http/Controllers/Ticket/TicketExportController.php](/var/www/php84/sms_admin_es/app/Http/Controllers/Ticket/TicketExportController.php)

#### C. Centralize export authorization

Create one reusable policy/service, for example:

- `App\Services\Security\ExportAccessService`

Its job:

- resolve current tenant
- resolve current user role
- check record ownership
- allow privileged overrides only for approved roles
- emit audit events for allow/deny

#### D. Move to secure export storage behavior

Recommended:

- keep exports in private storage only
- add expiry / retention cleanup job
- optionally move to GCS private bucket with signed URLs
- never expose raw predictable file paths in client responses unless required

### Phase 2: Add data classification and masking

Define 4 classes:

1. `Public`
2. `Internal`
3. `Restricted`
4. `PII / Sensitive`

Then map important fields:

- email
- phone number
- payment references
- invoice/customer exports
- support content
- IP address
- auth tokens
- company tax identifiers

Create reusable masking helpers, for example:

- `maskEmail()`
- `maskPhone()`
- `maskPaymentRef()`
- `maskToken()`

Rules:

- full data only for approved roles
- masked exports by default
- full export requires reason code and audit log

### Phase 3: Detect suspicious data-access behavior

Add a `data_access_events` stream for:

- export created
- export downloaded
- export previewed
- bulk customer query
- failed authorization attempt
- unusual tenant switching
- off-hours export burst

Recommended tables:

#### PostgreSQL

- `data_access_policies`
- `data_access_decisions`
- `security_incidents`
- `security_incident_notes`

#### ClickHouse

- `data_access_events`
- `data_access_signals`
- `data_access_feature_store`

Suggested first DLP rules:

- too many exports by one user in 1 hour
- too many downloads by one IP in 30 minutes
- download of another tenant's file id
- unusual CSV size compared with normal history
- access to support/customer exports outside normal hours
- repeated denied-download attempts

### Phase 4: Add secure delivery controls

Add these controls to sensitive exports:

- watermark PDF/image exports with user email + timestamp
- signed one-time download URLs
- short TTL for downloads
- manager approval for full unmasked export
- optional async export queue for large datasets
- automatic deletion after retention window

### Phase 5: Add alerting and incident response

Create alerts for:

- export/download spikes
- repeated denied downloads
- suspicious cross-tenant access attempts
- high-volume support/customer data export
- fraud rule spikes and gateway abuse

Operational flow:

1. detect suspicious event
2. open incident
3. freeze export or user session if threshold is severe
4. notify admin/security owner
5. capture evidence in audit log + case notes
6. close with resolution tag

## 6. 90-day implementation plan

### Days 1-15

- define fraud scope: auth abuse, refund abuse, promo abuse, messaging abuse
- define DLP scope: exports, downloads, PII exposure, cross-tenant access
- add explicit auth/authorization middleware to export routes
- create `ExportAccessService`
- add tenant and ownership checks to all export download endpoints
- create `fraud_events` and `data_access_events` schemas

### Days 16-30

- publish fraud events from refund, subscription, OTP, bulk SMS, and callback flows
- publish data access events from export create/download/preview actions
- add first rule set in observe-only mode
- add masking helper layer for customer/support/billing exports
- move export storage behavior to private-only handling

### Days 31-45

- create Filament `Fraud Alerts` page
- create Filament `Security Incidents` page
- add alert dashboards using ClickHouse
- add export retention cleanup job
- add download watermarking for PDF/image exports

### Days 46-60

- tune thresholds with real usage data
- add allowlist/blocklist management
- add analyst notes and case workflow
- add per-role full-vs-masked export policy
- add anomaly alerts for bulk downloads and failed authorization attempts

### Days 61-90

- build fraud feature store
- add first fraud model in shadow mode
- add DLP behavior scoring for suspicious export/download patterns
- add optional approval workflow for full unmasked exports
- document incident playbooks and operational ownership

## 7. First five implementation tickets I would do now

1. Add explicit middleware plus authorization checks to all export routes and download actions.
2. Create `ExportAccessService` and make every export controller use it.
3. Add `data_access_events` logging for export create, preview, and download.
4. Add `fraud_events` + `FraudEventPublisher` and hook refund, OTP, coupon, and SMS flows.
5. Build a small Filament `Fraud Alerts / Security Alerts` observe-only page before any blocking actions.

## 8. Practical rule of thumb for rollout

Roll this out in this order:

1. `Observe`
2. `Alert`
3. `Review`
4. `Step-up`
5. `Block`

That order will reduce false positives and keep the existing SMS platform stable while you add security controls.