How to Build a US Stock Trading App with Alpaca or DriveWealth: Broker-Dealer vs Partner Route
AI Summary: Building a US stock trading app requires choosing the right brokerage model, integrating trading APIs, and meeting regulatory requirements. This guide compares Alpaca and DriveWealth, explaining the broker-dealer and partner routes, key features, compliance considerations, and development costs. |
Building the screens of a stock trading app is the easy part. The hard part is deciding who is legally the broker. In the US, buying and selling securities for customers is a regulated activity. Someone in your stack must be a registered broker-dealer, and someone must clear trades and hold customer assets.
You can take on those roles yourself, or you can build on a broker that already holds them, through APIs from firms such as Alpaca or DriveWealth. This guide explains the roles, the three licensing routes, the broker-API account models, the compliance features you still need, and the architecture that ties it together.
For a side-by-side view of licences across the US, India, the UK and the EU, see our Fintech Licensing Requirements 2026 guide.
Who does what in a US stock trade
Role | What it does | Who usually plays it |
App / front end | User experience, onboarding screens, charts, order entry | You |
Introducing broker-dealer | Holds the customer relationship as a registered broker; sends orders on to a clearing firm | You (if registered) or your broker partner |
Clearing / carrying broker-dealer | Clears and settles trades, holds customer cash and securities, sends statements | A self-clearing broker, such as the broker behind a broker API |
Custody and settlement infrastructure | Settles trades and holds securities records | DTCC and its subsidiaries |
Market data | Prices, quotes and reference data | Exchanges, consolidated feeds and data vendors |
Since 28 May 2024, most US securities trades settle one business day after the trade (T+1), after an SEC rule change. Your funding, buying-power and statement logic must follow that cycle.
Three licensing routes
Route | What you register | What you build | Best for |
Own self-clearing broker-dealer | Broker-dealer with the SEC, FINRA membership, SIPC, state registrations, plus clearing memberships | Everything, including clearing, custody, books and records | Large firms that want full control of economics |
Introducing broker-dealer | Broker-dealer registration and FINRA membership; clearing through a carrying firm | Customer-facing brokerage and supervision; clearing is outsourced | Firms that want their own brokerage brand and licences |
App on a broker API (non-registered partner) | Usually none as a broker; the API provider is the broker of record | The app, onboarding UX, funding UX, content and support | Startups, fintechs and non-US firms adding US investing |
The SEC's Guide to Broker-Dealer Registration explains when a business must register, and the steps involved: filing Form BD, joining a self-regulatory organisation such as FINRA, SIPC membership and state requirements. What counts as "acting as a broker" depends on facts such as whether you are paid per transaction, handle customer funds or recommend securities, so get legal advice on your model before you launch.
What "introducing broker" really means
The term causes confusion. In the futures world, an "introducing broker" is a specific registration with the CFTC and the National Futures Association, for firms that take futures orders but do not accept customer money.
In US stocks, people use "introducing broker" loosely to mean a registered broker-dealer that introduces its customers to a clearing firm, which then carries the accounts. That firm still holds broker-dealer registration and FINRA membership. If you are not registered at all and build on a broker API, you are not an introducing broker. You are a technology partner, and the API provider's broker-dealer is the one your customers open accounts with.
Broker API account models
Broker APIs usually offer more than one way to hold customer accounts. Alpaca's Broker API, for example, supports fully disclosed, omnibus and OmniSub set-ups.
Model | How accounts are held | Typical user |
Fully disclosed | Each end customer has an account in their own name at the clearing broker | Apps and non-registered partners that want the broker to handle customer accounts |
Omnibus | The partner holds one account at the clearing broker and keeps sub-ledgers for its own customers | Registered brokers and institutions that keep their own customer books |
Hybrid (such as OmniSub) | Omnibus-style structure with sub-accounts | Partners that need some of both |
For most startups, fully disclosed is the simplest route: the broker opens and carries each customer account, runs the regulated KYC, and sends statements.
Alpaca and DriveWealth at a glance
Both firms describe themselves as API-first brokerage infrastructure. This is what their own documentation says.
Alpaca Broker API | DriveWealth | |
Regulatory status (per the firm) | Self-clearing broker-dealer; clears and custodies as a member of DTCC, FICC and OCC | FINRA and SEC registered |
Assets (per the firm) | US stocks including fractional, options, fixed income, crypto | US equities, ETFs, mutual funds, options, fixed income; fractional investing |
Onboarding | KYC as a service for non-registered technology partners | Built-in KYC and AML support, including for non-US customers |
Funding | Plaid, ACH and SWIFT; instant funding and other models | Account funding through the platform |
Events | Real-time events via Server-Sent Events | Event notifications via Amazon SQS |
Sandbox | Yes | UAT environment |
Docs |
Pricing, minimums and eligibility depend on your business and region, so request them from each provider. Other embedded brokerage providers exist too; compare them on asset coverage, account models, international support and how much of the compliance work they take on.
Compliance features you still have to build
Even when a broker partner is the broker of record, your app is the front door. Expect your partner to require these:
Customer identification and KYC: collect the data the broker needs (name, date of birth, address, tax ID, employment and investment profile) and pass it through their KYC flow
AML monitoring support: share signals about suspicious activity and respond to the broker's requests
Disclosures: show the broker's account agreements, risk disclosures and fee schedules at the right moments, and record acceptance
Recommendations: if your app recommends securities to retail customers, SEC Regulation Best Interest and related rules come into play; many apps stay self-directed to avoid this
Communications review: marketing, push notifications and in-app content may need review under the broker's supervisory procedures
Complaints: route customer complaints to the broker and keep records
Data security: protect personal and account data, and follow the broker's security requirements
If you also serve India, our SEBI and SEC compliance checklist for trading apps covers both markets.
Questions to ask a broker API provider
Before you sign, get clear written answers to these:
Which account models do you support, and which one fits a non-registered partner like us?
Which customers can we onboard: US residents only, or other countries too?
Which assets and order types are live, and which are on the roadmap?
Who handles KYC decisions, AML monitoring, statements, tax forms and customer complaints?
What marketing and in-app content do you need to review before we publish it?
How do funding and instant buying power work, and what happens when a deposit is returned?
What events do you send, how are they delivered, and can we replay missed ones?
What are the sandbox limits, and how does certification for production work?
What are the fees, minimums and contract terms?
The answers decide most of your architecture, so ask them before design starts.
Reference architecture
Layer | Components |
Client apps | iOS, Android and web; onboarding, watchlists, charts, order ticket, portfolio, statements |
Backend for front end | Session management, caching, rate limiting, feature flags |
Broker integration service | Account opening, KYC status, orders, positions, transfers; idempotent order submission |
Event processor | Consumes the broker's event stream (SSE, SQS or webhooks) for order fills, account and transfer updates |
Funding service | Bank linking (for example, Plaid), ACH transfers, funding status |
Market data service | Real-time quotes, charts and reference data, with entitlements |
Ledger and reconciliation | Your own view of orders, cash and positions, reconciled daily with the broker |
Compliance and audit | Disclosure acceptance, communications archive, complaints, audit logs |
Notifications | Order fills, price alerts, statements |
Two design rules save pain later. First, treat the broker as the source of truth for orders and positions, and reconcile your own records with it every day. Second, make order submission idempotent so a retry never creates a duplicate trade.
Our guide on market data APIs for trading apps covers the data layer in more depth.
Cost and timeline drivers
We do not quote fixed prices without a scope. These are the main drivers:
Route: an app on a broker API is far smaller than a registered broker-dealer, which also needs registration, staff and supervisory systems
Assets: adding options or crypto adds approvals, disclosures and new order types
Real-time features: streaming quotes and live charts need more infrastructure and data licences
International users: non-US customers bring tax forms, extra KYC and funding work
Apps: native apps on both platforms cost more than a web app
For a broader view of budgets, see how much it costs to develop a stock trading app.
A phased plan
Pick your route and broker partner, and confirm the account model.
Build onboarding and KYC on the broker's sandbox.
Add funding, then orders, positions and the event processor.
Add market data, watchlists and notifications.
Add statements, tax documents, complaints and the compliance archive.
Run end-to-end tests with the broker, then launch to a small group.
Build your trading app with Fintegration
Fintegration builds trading and investing apps for the US and India, including broker API integrations, funding, market data and compliance features. Talk to our team to plan your US stock trading app.
FAQ
1. How do I build a US stock trading app?
Start by choosing a brokerage model, integrating a brokerage API, setting up KYC/AML checks, and building essential features like account funding, stock trading, and portfolio tracking.
2. What is the difference between Alpaca and DriveWealth?
Both provide brokerage infrastructure and APIs, but their offerings, integration models, supported services, and partnership requirements differ.
3. Do I need a broker-dealer licence to launch a stock trading app in the USA?
Not always. You may work with an appropriately registered broker-dealer, but your own activities and business structure determine whether registration is required.
4. What is the broker-dealer vs. partner route?
The broker-dealer route involves obtaining the required registrations yourself, while the partner route lets you work with an existing licensed brokerage provider.
5. How much does it cost to build a US stock trading app?
Costs depend on API fees, brokerage partnerships, compliance, development, security, and infrastructure. The partner route may reduce initial setup costs.
