Meeting Recording Compliance for Financial Services

A wealth manager takes a client call on Zoom and discusses a portfolio rebalancing recommendation. Under compliance meeting recording finance regulations in the European Union, that conversation must be recorded, retained for a minimum of five years, and producible on demand to regulators. Under FINRA rules in the United States, the requirements are similar. The wealth manager uses the native Zoom recording feature, which stores the file in Zoom's cloud infrastructure with retention policies Zoom controls. When a compliance audit request arrives two years later, the legal team discovers that the auto-delete setting was enabled. The recording is gone.

This scenario plays out regularly in financial services organizations that treat meeting recording as an afterthought. The regulatory requirements are real and well-established, but the tooling to implement them correctly, with audit trails, controlled retention, verifiable integrity, and access logging, requires more than checking the "record this meeting" box. It requires a recording infrastructure layer that your organization controls.

For developers building fintech products or internal compliance tooling for financial services firms, this post covers the three major regulatory frameworks that mandate call recording, the specific technical controls required, and how to implement them using a meeting recording API as the infrastructure layer. The goal isn't to replicate a law firm's analysis, you need a compliance attorney for that but to give you an accurate technical picture of what the regulations require and what you need to build.

The Regulatory Landscape: Three Frameworks That Matter

Three regulatory frameworks create the primary recording obligations for financial services firms communicating with clients about investment products and services.

MiFID II (the Markets in Financial Instruments Directive, revised) Article 16(7) requires European investment firms to record all communications that relate to, or are intended to lead to, the conclusion of a transaction. This applies to orders received via telephone, video call, or any electronic communication system. Recordings must be retained for at least five years and, where a national competent authority requests it, up to seven years. Firms must inform clients before providing services that their communications may be recorded, and clients cannot waive this requirement.

FINRA Rule 3110 in the United States requires broker-dealer member firms to supervise their business activities, which the Financial Industry Regulatory Authority has interpreted to include retention of communications with clients. FINRA Rule 4511 mandates retention of business communications for six years minimum. While FINRA doesn't specify video call recording in the same way MiFID II does, the evolving interpretations, particularly accelerated by enforcement actions during the pandemic when firms moved to remote communication, have made comprehensive recording the de facto standard for broker-dealers.

Dodd-Frank requirements applicable to swap dealers and major swap participants include mandatory recording and retention of oral and written communications related to potential swap transactions. The relevant CFTC regulation (17 CFR 23.202) requires retention for at least five years. The SEC equivalent under Rule 17a-4 requires electronic communications retention in a write-once, read-many format, a technical requirement that has significant implications for how you store recordings.

These are the baseline frameworks. Many jurisdictions have additional requirements: the FCA in the UK, ASIC in Australia, SEBI in India. If you're building for a firm that operates in multiple jurisdictions, assume the most stringent requirement across all jurisdictions applies to every recording.

What "Compliance Recording" Actually Requires Technically

The regulations translate to a specific set of technical requirements that go well beyond storing a video file. Here's what you need to implement:

Retention period enforcement: recordings must be retained for the required period and must not be deletable within that period by unauthorized parties. This maps to a write-protected storage configuration with time-locked deletion. AWS S3 Object Lock in Governance or Compliance mode implements this at the storage layer, objects in Compliance mode cannot be deleted by anyone, including the root account, until the lock expires.

Verifiable integrity: you need to demonstrate that a recording wasn't tampered with between the time it was made and the time it's produced in an audit. The standard approach is to compute a hash (SHA-256) of the recording file at the time of storage and store the hash in a separate, append-only audit log. When producing the recording in an audit, you recompute the hash and compare. A mismatch indicates tampering.

Access logging: every access to a recording, who viewed it, when, and for what purpose, must be logged. Audit logs themselves must be retained and tamper-evident. This requires an append-only log store (a separate database table where rows can't be updated or deleted, or an immutable log service).

Financial meeting transcription (not just recording) creates an additional compliance artifact. Under some interpretations of the record-keeping rules, searchable transcripts with speaker attribution and timestamps may be required in addition to audio/video recordings. Even where not strictly required, transcripts substantially reduce the cost of responding to regulatory inquiries, searching a text transcript is faster than scrubbing through a recording.

Implementing Retention with the MeetStream API

When deploying a recording bot via the MeetStream API, the recording_config parameter controls where recordings go and how they're stored. For compliance use cases, you'll configure this to deliver recordings to your own infrastructure rather than relying on any third-party storage. This is critical: the regulatory obligation is yours, not your recording vendor's.

The implementation pattern:

POST https://api.meetstream.ai/api/v1/bots/create_bot
Authorization: Token YOUR_API_KEY

{
  "meeting_link": "https://zoom.us/j/123456789",
  "bot_name": "Compliance Recorder",
  "callback_url": "https://your-compliance-api.com/webhooks/meetstream",
  "recording_config": {
    "retention_period_days": 1825
  }
}

A retention of 1,825 days is five years. For MiFID II contexts where seven years may be required by national authority request, use 2,555 days. Your webhook handler receives the audio.processed event with a download URL. At this point, your compliance pipeline takes over: download the file immediately, compute the SHA-256 hash, upload to your S3 bucket with Object Lock enabled (setting a retention date equal to today plus the required retention period), and write a record to your audit log: file hash, S3 location, recording date, participants, meeting ID, hash computation timestamp.

The download-hash-store sequence should be atomic from an audit perspective. A failure after download but before hash storage creates an unverifiable recording. Build idempotent retry logic: if the pipeline fails after download, re-download and re-hash rather than assuming the previous attempt succeeded.

Encryption Requirements

Encryption at rest is required under most financial services information security frameworks, and the GDPR-adjacent requirements in many jurisdictions make it a baseline expectation even where not explicitly mandated by a specific call recording regulation.

For recordings stored in S3, server-side encryption with AWS Key Management Service (SSE-KMS) provides encryption at rest with key management under your control. Use customer-managed keys (CMK), not AWS-managed keys, this gives you the ability to rotate, audit, and if necessary revoke access to decryption keys. Log all key usage in CloudTrail.

Encryption in transit is provided by HTTPS for both the MeetStream API callback and the download URL for completed recordings. Verify that your webhook handler enforces TLS 1.2 or higher on incoming connections and that your S3 upload uses the AWS SDK with signature v4 authentication.

For the audit log, encryption matters too. A tamper-evident audit log that is itself unencrypted and accessible to database administrators defeats part of its purpose. Use database-level encryption or a separate encrypted log store. Access to the audit log should be restricted to compliance officers and logged separately from general application access.

Disclosure Requirements and Bot Configuration

MiFID II explicitly requires that clients be informed before services are provided that their communications will be recorded. In a video call context, this typically happens in two places: in the pre-call disclosure (in the meeting invitation, client portal, or terms of service), and in-call when the recording bot joins.

The MeetStream API's bot_name parameter controls how the bot appears in the meeting. For compliance contexts, use a name that clearly identifies the recording function: "Compliance Recorder" or "[Firm Name] Compliance Bot." This provides visible, in-meeting disclosure that a recording is in progress. Some firms also use MIA's Chat action type to post an in-meeting message when the bot joins: "This meeting is being recorded and retained for regulatory compliance purposes. By continuing, you consent to this recording."

Store the disclosure confirmation as part of your call record. The bot's join time (from the bot.inmeeting webhook) provides a timestamp for the in-call disclosure. Combined with your pre-call disclosure documentation, this creates a defensible compliance record.

Responding to Regulatory Requests

The practical value of well-implemented compliance recording infrastructure becomes clear when a regulator requests records. Typical requests specify: a date range, one or more parties (employee name, customer name, account number), and the type of communication. Your system needs to retrieve matching recordings and transcripts within a legally-specified timeframe, often five business days.

This requires a queryable metadata store indexed on: recording date, participant names, account numbers (if associated at bot creation time), meeting platform, and meeting ID. The recordings themselves live in S3 and don't need to be indexed, but the metadata about each recording must be queryable.

Build the regulatory request workflow as a first-class feature: an admin interface that accepts the request parameters, queries the metadata store, retrieves the relevant recordings from S3, verifies the hash against the stored hash (integrity check), and packages the output, recordings, transcripts, hash verification report, access log for the relevant records, into a structured response. Document the process in a runbook so it can be executed consistently even if the person who built the system is no longer available.

What MeetStream Provides vs. What You Build

Being precise about the responsibility split helps avoid compliance gaps. The MeetStream API provides: reliable bot join and leave across Google Meet, Zoom, and Teams; audio and video recording; speaker-attributed transcription; webhook delivery of recording and transcript artifacts. These are the recording capture components.

Your application is responsible for: storage architecture meeting regulatory requirements (Object Lock, encryption), hash computation and integrity verification, access logging, retention period enforcement, disclosure workflow, regulatory request response, and organizational record-keeping procedures. The recording infrastructure is an input. Compliance is a system-level property of your implementation.

This distinction matters when you're discussing the system with your compliance officer or legal counsel. MeetStream captures the meeting content reliably. The compliance controls, retention, integrity, access control, disclosure, are implemented in your application using the captured content as input.

Frequently Asked Questions

Does MiFID II apply to video calls as well as phone calls?

Yes. MiFID II Article 16(7) applies to all communications that relate to the conclusion of client transactions, regardless of the communication medium. The European Securities and Markets Authority's guidance has confirmed this applies to video conferencing. The pandemic enforcement actions by the FCA (which enforces MiFID II in the UK) against firms that moved to video calls without updating their recording compliance frameworks confirmed that video calls are within scope.

What's the technical difference between Governance mode and Compliance mode in S3 Object Lock?

In Governance mode, users with the s3:BypassGovernanceRetention IAM permission can delete or modify locked objects before the retention period expires. This provides protection against accidental deletion while allowing authorized administrators to override. In Compliance mode, no user, including the AWS root account, can delete or modify locked objects before the retention period expires. For call recording finance compliance use cases where regulations mandate that records cannot be deleted for a fixed period, Compliance mode is the appropriate choice. Be careful: objects in Compliance mode with long retention periods create permanent storage obligations that cannot be reversed.

How do you handle recordings when an employee leaves the firm?

The recording obligation runs with the communication, not the employee. Recordings made while the employee was at the firm must be retained for the required period regardless of their employment status. Archive recordings associated with departed employees to cold storage (S3 Glacier) to reduce cost, but maintain the same retention policy and access logging. The metadata record linking the recording to the employee should remain queryable. Include a process in your employee offboarding checklist that verifies recording metadata is updated with the employee's departure date and that retention policies are confirmed.

Is transcription required for MiFID II compliance, or just the audio/video recording?

MiFID II as written requires retention of the communication itself, which means the audio or video recording. Transcription is not explicitly required. However, the practical cost of responding to regulatory inquiries without transcripts is high, scrubbing through audio is slow and error-prone. Many compliance-focused firms treat transcription as a de facto requirement because the cost of not having searchable transcripts during an inquiry is significant. It's worth discussing with your compliance officer whether to treat transcription as required or as a best practice in your specific context.

Can you use a meeting recording API for compliance if the API vendor isn't in the EEA?

Under GDPR, transferring personal data (which meeting recordings containing identifiable individuals are) to a third country requires either an adequacy decision, Standard Contractual Clauses, or other approved transfer mechanism. For a US-based meeting recording vendor, you need appropriate transfer mechanisms in place. This is a legal question for your data protection officer, but the technical implementation should ensure that data processing agreements (DPAs) are in place with all vendors who process personal data, and that data residency requirements (some regulated firms need data to remain in the EU) can be met. Discuss your specific jurisdictional requirements with legal counsel before selecting infrastructure vendors for compliance-sensitive recording.

If you're building compliance recording infrastructure for a fintech meeting bot use case, the MeetStream documentation covers the recording configuration parameters and webhook events that form the basis of a compliant recording pipeline. The recording capture layer is a solved problem; the compliance controls are the product you're building on top of it.