Offshore Engineering Under FINRA Notice 21-29

Whenever I sit down with the CTO, CISO, or Chief Compliance Officer of a US broker-dealer, SEC-registered investment adviser, or wealth management platform, the conversation inevitably hits the same early roadblock. They like the architecture, and they value that our senior engineers have built order systems, portfolio platforms and multi-account AWS landing zones before.

Then comes the first objection:

"Part of your engineering team is outside the United States. How do we justify an offshore engineering partner to our CCO and our FINRA examiners under Regulatory Notice 21-29?"

It is a fair question—and in regulated financial services, it should be the very first one you ask. Too many offshore dev shops treat compliance as someone else's problem, asking for broad VPN access, copying production databases to local staging servers, and rotating junior developers in and out of accounts without warning. If you bring a vendor like that into a regulated environment, your next examination will be painful.

This article explains what FINRA Regulatory Notice 21-29, FINRA Rule 3110 (Supervision) and SEC Regulation S-P actually expect when a firm uses an outside engineering team, how to set the technical boundaries so location stops being the risk, and the evidence a compliance team needs to defend the relationship. It applies to any offshore vendor, not only to us.

1. What FINRA Regulatory Notice 21-29 Actually Says

A common misconception among technology leaders is that FINRA prohibits broker-dealers from using non-US engineering teams. It does not.

What FINRA Regulatory Notice 21-29 (and the foundational Rule 3110 on Supervision) establishes is a strict principle of accountability: a member firm can outsource a technical function, but it can never outsource its supervisory responsibility for that function.

When FINRA examines a member firm's third-party vendor relationships, they aren't looking for a zip code; they are looking for governance across four specific lifecycle phases:

1. The Outsourcing Decision: Did the firm assess the risk of the vendor's access to sensitive firm systems or Customer Non-Public Personal Information (NPI)?
2. Due Diligence: Did the firm verify the vendor's technical controls, cybersecurity posture, background screening, and sub-contracting practices prior to engagement?
3. Onboarding & Contracting: Are roles, responsibilities, data-handling rules, and incident notification timelines explicitly locked into written agreements and Written Supervisory Procedures (WSPs)?
4. Ongoing Supervision: How does the member firm continuously monitor the vendor's code changes, access privileges, and technology change management?

In short, FINRA doesn't fail firms because an engineer wrote Terraform or .NET Core from outside the US. FINRA cites firms when they grant an external team unsupervised access to customer data, fail to enforce least-privilege controls, or lack an immutable audit trail of who changed what.

2. Solving the #1 Fear: Data Access from Offshore

When a CCO hears "offshore engineering," their immediate concern under SEC Regulation S-P and FINRA Notice 21-29 is Customer NPI crossing borders or sitting on an engineer's laptop halfway around the world.

A policy promise doesn't answer that concern; architecture does. Design the engagement so that customer production data never leaves your environment and is never accessible to our day-to-day build teams.

Keeping customer data inside the firm's boundary

This is how we set up every engagement:

• Data Stays in the Client's Boundary: We never copy client production data onto Bingeable Tech systems. Development, testing, and CI/CD validation run strictly against synthetic or deterministically masked datasets.
• Environment Isolation: When we build or maintain your AWS landing zones, we enforce strict multi-account separation between dev, staging, and prod. Offshore and distributed engineers build and test in non-production accounts that contain no real customer records. Our AWS foundations for a wealth manager shows this account structure in practice.
• Client-Managed Identity & The "Kill Switch": We don't ask for shared admin credentials. Our engineers authenticate through your SSO into tightly scoped, short-lived AWS IAM roles. Your security team retains the primary audit log and holds the unilateral off-switch to revoke our access in seconds.
• No Open SSH Ports: We eliminate traditional bastion hosts and open inbound ports. When infrastructure troubleshooting is required, sessions are brokered exclusively through AWS Systems Manager (Session Manager) with each session's commands and output logged to write-once S3 buckets (S3 Object Lock) inside your account.
• Governed AI Boundaries: Client code and schemas are never pasted into public LLMs. Any AI-assisted engineering or product features we build run over private endpoints (such as Amazon Bedrock inside your VPC) with no model training on your data, as in our audit-ready AI feature for a broker-dealer.

When you can show an auditor that your external engineering team cannot query production PII, cannot download database dumps, and operates exclusively inside your logged identity boundary, where they sit matters far less.

3. How We Enable Your FINRA Rule 3110 Supervision

Notice 21-29 requires your designated principals and engineering leaders to supervise the vendor's technology change management and cybersecurity controls. If you hire a traditional "black-box" agency where 20 unnamed offshore developers push code behind the scenes, you cannot credibly claim supervision.

Supervision works when it is built into the engineering workflow:

Named engineers, no subcontracting

FINRA specifically instructs firms to scrutinize "relationships between Vendors, sub-contractors and other third-parties." At Bingeable Tech, we never subcontract your work to third parties, and the senior architects and engineers you meet during scoping are the exact people writing the code and attending your architecture reviews.

Every change reviewed before it merges

Notice 21-29 asks how a member firm can "become aware of, evaluate and, as appropriate, test the impact of changes Vendors make to their applications and systems."

• Every line of application code and infrastructure-as-code (Terraform/Kubernetes) we write goes through version-controlled Pull Requests.
• Every change requires second-engineer review, automated CI security scanning, and Open Policy Agent (OPA) policy-as-code checks before it can merge.
• For production releases, your internal technical lead or designated principal holds the final merge/deployment approval gate. We build the release; you turn the key.

Screening and devices for engineers outside the US

Our HR and compliance team maintains jurisdictional equivalence for every engineer outside the US:

• Comprehensive international criminal, identity, education, and primary-source employment background checks completed prior to onboarding.
• Centrally managed, encrypted company laptops configured for remote wipe, with mandatory hardware-backed MFA across all accounts.
• Same-day offboarding protocols that revoke internal and client-scoped access within hours of an engagement change or departure.

4. Cheat Sheet: Answering Your Due Diligence Questionnaire (DDQ)

When your Vendor Risk Management (TPRM) team or CCO sends out a due diligence questionnaire aligned with FINRA Notice 21-29, the answers should be ready on day one. These are the five hardest offshore questions, and the controls and evidence we answer them with:

FINRA Notice 21-29 Focus Area	The CCO / Auditor Question	Control and evidence
Data Protection & SEC Reg S-P	"Will offshore personnel have access to Customer NPI or production financial records?"	No. Engineers work strictly in isolated dev/staging accounts using synthetic data. Production access is blocked by default; emergency break-glass access requires client approval and is fully session-logged.
Access Controls & Least Privilege	"How is vendor access provisioned, monitored, and revoked?"	Access is federated via Client SSO + scoped IAM roles with mandatory MFA. Reviewed quarterly against HR rosters; same-day revocation SLA upon offboarding.
Change Management Supervision	"How does the member firm supervise code and infrastructure changes made by the vendor?"	100% GitOps workflow. Mandatory PR reviews, automated static/policy-as-code (OPA) checks, and client sign-off gates prior to production deployment.
Personnel Screening & Subcontractors	"Are non-US personnel background-checked, and does the vendor use fourth-party subcontractors?"	Zero fourth-party subcontracting. 100% of engineers undergo cross-border criminal, identity, and primary-source employment/education verification prior to access.
Books, Records & Audit Trails	"Can the firm and FINRA examiners access complete audit trails of vendor activity?"	Yes. Because we operate inside your cloud and source-control boundary, all CloudTrail logs, Session Manager transcripts, and Git commit histories live in your write-once (S3 Object Lock) storage.

Checklist: what to ask any offshore engineering vendor

1. Will any of the vendor's staff be able to reach customer NPI or production data? If yes, how is that access approved, limited in time and logged?
2. Do the vendor's engineers sign in through your SSO with MFA, or with credentials you don't control?
3. Can your security team revoke all of the vendor's access on its own, and how quickly?
4. Where do the audit trails of vendor activity (cloud logs, sessions, code history) live, and can your firm keep them for as long as your records rules require?
5. Who reviews each code and infrastructure change, and who approves production releases?
6. Does the vendor use subcontractors, and will you know every person working on your systems?
7. What background checks are done on staff outside the US, and can the vendor show the evidence?
8. How fast is access removed when someone leaves the engagement, and how is that checked?
9. What does the contract say about incident notification, data handling and your right to audit?

Location isn't the risk; engineering hygiene is

Offshore engagements fail a FINRA or SOC 2 review because of shared credentials, manual server changes and unvetted contractors, not because of geography. A vendor working that way is a liability whether it sits in New York or halfway across the world.

Audit evidence should be a by-product of disciplined engineering. See how we work with broker-dealers and investment advisers, or talk to an engineer about your vendor review.

This article describes what systems can do and what FINRA and the SEC have published. It isn't legal or compliance advice; your CCO and counsel decide what applies to your firm.