DEV Community

Cover image for FINRA-Compliant Storage with S3 Object Lock: A Practical Guide for 2026
Ethan Carter
Ethan Carter

Posted on

FINRA-Compliant Storage with S3 Object Lock: A Practical Guide for 2026

#finra #compliance #s3 #rustfs

FINRA Rule 17a-4(f) requires WORM storage. Here's how S3 Object Lock satisfies it on self-hosted infrastructure — with implementation examples and a comparison of which systems actually support compliance-mode locking.

Key Stats

Metric Figure
FINRA enforcement actions citing recordkeeping (2025) ~340
Avg fine per firm for recordkeeping deficiencies $225K
Firms using cloud WORM storage for 17a-4(f) ~73%

What FINRA Actually Requires

Three rules matter:

SEC Rule 17a-4(f) — Electronic records must be stored in either:

  • Option A (WORM): Non-rewriteable, non-erasable format — no one can modify or delete records until retention expires.
  • Option B (Audit Trail): Complete time-stamped audit trail of every modification/deletion.

Option A is easier to defend in exams because the technology prevents tampering. Option A's digital standard: S3 Object Lock in Compliance mode.

FINRA Rule 4511(c) — Records must be indexed, accessible (first 2 years immediately), and reproducible.

FINRA Rule 3110 — Supervisory controls preventing unauthorized modification.

Compliance Mode vs. Governance Mode

This is the critical distinction:

Compliance Mode:   locked → NO ONE can delete → ✅ FINRA OK
Governance Mode:  locked → root CAN bypass    → ⚠️ Need extra controls
Enter fullscreen mode Exit fullscreen mode

For FINRA examination purposes, Compliance mode is the standard answer.

Which Systems Support Object Lock

System Object Lock Compliance Mode Legal Hold
AWS S3 ✅ ✅ ✅
RustFS ✅ (v1.2+) ✅ ✅
MinIO ✅ ✅ ✅
Ceph RGW Partial Limited ❌
Wasabi ✅ ✅ ✅
SeaweedFS ❌ ❌ ❌
Garage ❌ ❌ ❌

SeaweedFS and Garage don't implement Object Lock at all. If you're using them for regulated data, you'll need an external WORM layer.

Implementation: Step by Step

Using RustFS as the S3-compatible backend (same pattern applies to any compliant system):

Step 1: Enable Object Lock at Bucket Creation 

aws --endpoint-url http://localhost:9000 s3api create-bucket \
  --bucket finra-compliance-records \
  --object-lock-enabled-for-bucket
Enter fullscreen mode Exit fullscreen mode

Object Lock must be enabled at creation — can't be added to existing buckets.

Step 2: Set Default Retention (6 years) 

aws --endpoint-url http://localhost:9000 s3api put-object-lock-configuration \
  --bucket finra-compliance-records \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 2200
      }
    }
  }'
Enter fullscreen mode Exit fullscreen mode

Step 3: Upload with Retention 

import boto3
from datetime import datetime

s3 = boto3.client('s3',
    endpoint_url='http://localhost:9000',
    aws_access_key_id='your-key',
    aws_secret_access_key='your-secret',
)

# Trade record: 6-year retention
s3.put_object(
    Bucket='finra-compliance-records',
    Key='trades/2026/07/T123456.json',
    Body=open('T123456.json', 'rb'),
    ObjectLockMode='COMPLIANCE',
    ObjectLockRetainUntilDate=datetime(2032, 7, 24),
)
Enter fullscreen mode Exit fullscreen mode

Step 4: Verify Immutability (Critical!) 

# Try deleting a locked object — should FAIL with 403 AccessDenied
aws --endpoint-url http://localhost:9000 s3api delete-object \
  --bucket finra-compliance-records \
  --key trades/2026/07/T123456.json

# Error: "The object is locked with COMPLIANCE mode retention..."
Enter fullscreen mode Exit fullscreen mode

Document this test. Screenshot the error. Keep it for examiners.

Retention Strategy by Record Type

Record Type Retention Days
Trade confirmations & order tickets 6 years 2200
Customer account records 6 yrs post-closure 2300
Customer communications 3 years 1100
Blotters & ledgers 6 years 2200
Complaint records 4+ years 1500+legal hold
Marketing materials (RIAs) 5 years 1850

Create separate buckets per retention tier — simplifies auditing.

Self-Hosted vs. Cloud for FINRA Workloads

Factor Self-Hosted (RustFS) Cloud (AWS/Wasabi)
WORM capability ✅ ✅
Examiner familiarity ⚠️ Needs explanation ✅ Ends questions
Cost at 100TB+ ✅ 3–5x cheaper 💰 Egress adds up
Data sovereignty ✅ You control it ⚠️ Region-dependent
D3P ecosystem Less common Well-established

Self-hosting wins when you have 50TB+, existing ops capacity, or data residency needs. Cloud wins for smaller firms prioritizing examiner familiarity.

Where Self-Hosted Gets Tricky

  1. D3P designation is harder with self-hosted infra (cloud has established ecosystems)
  2. Examiner skepticism — be ready with documentation, test results, config screenshots
  3. Version upgrades need regression tests against WORM guarantees
  4. DR replica must also enforce Object Lock (compliance gap if it doesn't)

None are deal-breakers — just budget engineering time accordingly.

Pre-Exam Checklist

  • [ ] Object Lock enabled on all compliance buckets (at creation)
  • [ ] Default retention = Compliance mode (not Governance)
  • [ ] Retention periods match record-type requirements
  • [ ] Legal hold mechanism tested and documented
  • [ ] Failed delete attempts documented (screenshots!)
  • [ ] DR replica also enforces Object Lock
  • [ ] WSPs reference storage architecture
  • [ ] D3P designation filed

Bottom Line

FINRA doesn't care if your WORM storage runs on AWS or your own RustFS cluster. What matters: can you prove tamper-proof retention, produce records fast, and demonstrate it to an examiner?

S3 Object Lock in Compliance mode is the clearest path because the technology makes violations impossible — not just against policy. For self-hosted teams, RustFS offers full Object Lock parity with AWS S3. Verify your version, test adversarially, document everything.

FAQ

Does FINRA require cloud storage, or can I self-host?

FINRA does not mandate cloud storage. What it mandates (via SEC Rule 17a-4(f)) is that electronic records be stored in a non-rewriteable, non-erasable format — WORM — for the applicable retention period. If your self-hosted S3-compatible system implements Object Lock in Compliance mode with tamper-proof retention, it can satisfy the WORM requirement. The key is whether your storage system's immutability controls meet the regulatory standard, not who hosts the servers.

What's the difference between Governance mode and Compliance mode for Object Lock?

Governance mode allows users with special IAM permissions (like s3:BypassGovernanceRetention) to overwrite or delete an object before retention expires. Compliance mode does not — no user, not even root or account admin, can delete or overwrite a locked object until retention expires. For FINRA Rule 17a-4(f) compliance, you need Compliance mode. Governance mode is useful for internal data governance but doesn't satisfy regulatory WORM requirements.

How long do I need to retain records under FINRA rules?

It depends on the record type. Most customer communications and trade records require 3–6 years. Customer account records need 6 years after account closure. Blotters and ledgers typically require 6 years. Complaint records need at least 4 years (often longer if litigation risk exists). The first 2 years must be "easily accessible" — meaning regulators can get them quickly without special procedures. Years 3+ can be on slower/colder storage but still retrievable on request.

Can RustFS or MinIO handle FINRA-grade Object Lock?

RustFS supports S3 Object Lock in both Governance and Compliance modes as of v1.2+. MinIO also supports Object Lock. Both implement the same S3 API (put-object-retention, get-object-retention, put-object-legal-hold). For production FINRA workloads, verify your specific version supports the full Object Lock API surface, test retention enforcement with an adversarial attempt (try deleting a locked object as root), and document the configuration for your examiner.

What happens during a FINRA exam if my storage doesn't support Object Lock?

FINRA examiners evaluate whether your storage architecture satisfies SEC Rule 17a-4(f)'s immutability requirement. If you're using standard (non-WORM) object storage, you'll need to demonstrate an alternative compliant approach — such as a complete audit trail system that logs every modification/deletion with timestamps and identities (the "audit trail alternative" added in the October 2022 rule amendments). This is harder to defend in an exam than true WORM storage because you're proving a process works rather than demonstrating that the technology makes violations impossible.

Not legal advice. Consult qualified securities counsel. Last updated: July 2026.

Top comments (0)