Legacy WealthTech Platform Modernization for an SEC-Registered Investment Adviser Serving 450K+ Investors

The client is a New York-headquartered SEC-registered investment advisory firm founded over two decades ago, serving a 450K+ digital investor community across the United States. The firm translates institutional-style research and portfolio management into subscription-based advisory services for self-directed retail and mass-affluent investors. Its operation combines investment, editorial, and compliance teams working under SEC/RIA content approval and recordkeeping workflows.

The client launched its digital product to scale advisory services beyond manual, high-touch workflows and create a subscription-based channel for proprietary research, portfolio guidance, market analytics, and investment commentary. The first version, built by a previous vendor, brought the firm’s subscription business online and gave investors 24/7 access to research and portfolio guidance through mobile and web.

 

As the subscriber base and system complexity grew, the original architecture could no longer support the product’s availability, release pace, and compliance requirements. The system was structured as microservices on paper but behaved like a coupled monolith in production. Small changes routinely caused regressions. Rollbacks were manual and slow. Production issues took too long to investigate because logging, observability, and automated regression coverage were incomplete.

 

The defects had direct business impact. Subscription states could drift across services after partial payment or service failures, causing billing inconsistencies, stuck renewals, and delayed access updates. Time-sensitive market and portfolio alerts were delivered late or inconsistently. Audit trail gaps created additional work for the compliance team and increased SEC/RIA recordkeeping risk.

 

For an SEC-registered investment adviser, this was unacceptable. The existing team could not keep production stable and deliver required changes in parallel. The client engaged Itexus for an independent technical audit, and the audit showed that isolated fixes would not help: the platform needed controlled refactoring of core flows, a more reliable data model, stronger observability, automated regression coverage, and a release process that would not destabilize production.

 

After several unsuccessful attempts to address the issues with the incumbent vendor — including two months of post-audit guidance from Itexus — the client transferred the entire platform to Itexus for stabilization, refactoring, and further development.

The modernized platform serves four operating roles plus an AI layer that supports all of them. Trade execution and custody remain with investors’ brokerage accounts. The platform delivers advisory content — research, model portfolios, alerts, and education — not order flow, keeping the product in investment-adviser scope without broker-dealer or custody workflows.

 

1. Investor experience

 

For self-directed retail and mass-affluent subscribers accessing the platform through iOS, Android, and web.

 

Subscribers can:

• Read research, follow model portfolios, watch educational content, and manage subscription plans

• Receive market and portfolio alerts across push, email, SMS, and secondary messaging channels — same content, same timing, same approved version on every surface

• See the content their subscription tier entitles them to: research, model portfolios, alert streams, premium materials, and educational content

• Complete identity verification, sanctions and PEP screening through GBG at onboarding, and acknowledge Form ADV Part 2 brochure delivery at subscription start and annual update

• Access cached portfolio state, recent approved research, and pending alerts when offline, with the last update time clearly marked

Subscriber geography is tracked against the firm’s state registrations, with geo-aware controls on content delivery and onboarding for states where the firm has notice filings or registration status. GBG screening can feed the firm’s Identity Theft Prevention Program under Reg S-ID where applicable, flagging anomalous identity patterns for compliance review.

 

All content is rendered through native Flutter widgets rather than embedded WebViews — approved research, performance displays, and disclosure blocks stay inside the app’s access control, versioning, and audit rules.

 

2. Analyst workspace

 

For portfolio managers, research analysts, and editors producing advisory content.

 

Portfolio managers and analysts can:

• Build and rebalance model portfolios — set target allocations, select instruments, assign benchmarks, and track rebalancing history

• Draft portfolio updates with thesis, rationale, affected instruments, and target subscriber segment

• Prepare market commentary, earnings notes, and research with full version history (what changed, when, by whom)

• Schedule publication across mobile, web, email, push, and secondary messaging channels

• Access market data, fundamentals, research, and news from Refinitiv, Polygon.io, Morningstar, Reuters, and MT Newswires through one workspace

3. Compliance review and recordkeeping

 

For compliance reviewers operating under SEC Rule 204-2 and SEC Marketing Rule 206(4)-1.

 

Compliance reviewers can:

• Approve content before publication and classify it as general commentary, subscription research, model portfolio update, educational material, or profile-sensitive advisory communication

• Attach required disclosures, risk language, and Form ADV references to specific content versions

• Run SEC Marketing Rule checks on performance materials — net-of-fees presentation, standard time periods, and labeling of hypothetical or backtested results

• Review every advisory communication with full context: content, timestamp, recipient, channel, approval status, and reviewer identity

• Export records in SEC examination-ready packages with indexed records, delivery metadata, approval history, and source content

Subscriber alerts are recorded as advisory communications in their own right, linked to the approved content version they referenced. Records follow the applicable Rule 204-2 retention schedule, including five-year retention for covered advisory records.

 

4. Back office and operations

 

For finance, operations, and support teams running the business behind the product.

 

Operations and support teams can:

• Monitor the full subscription lifecycle from one operational view — payments, renewals, access rights, notifications, and support escalations

• Investigate stuck renewals, delayed access updates, failed notifications, and support escalations with per-subscriber timelines across billing, content access, alert delivery, and support actions

• Handle chargeback workflows: pause subscriber access, collect dispute evidence from billing and engagement records, and sync resolution status back to Salesforce

• Reconcile Stripe payouts into QuickBooks — revenue by subscription tier, deferred revenue for prepaid annual plans, refund and chargeback categorization, and per-state sales tax handling

• Manage retention and lifecycle workflows in Salesforce alongside Form ADV Part 2 brochure delivery records, disclosure acknowledgements, and client communication history

• Track product, conversion, engagement, and retention metrics through Segment with server-side collection that keeps investor PII out of third-party SDKs

Form ADV delivery records are handled under Rule 204-3 workflows, while advisory communications and related records remain inside the Rule 204-2 recordkeeping perimeter.

 

5. AI-assisted advisory analytics

 

For analysts, investors, and compliance reviewers — supported by LLMs, RAG workflows, and domain-specific agents.

 

The AI layer:

• Writes plain-English explanations of why portfolios moved — connecting holdings to sector moves, news events, and research

• Runs monitoring agents over portfolios and market events 24/7, surfacing relevant changes and drafting alerts for analyst review

• Summarizes earnings notes, research, and educational content for editors

• Powers natural-language search across research, alerts, portfolio updates, disclosures, and prior communications

• Provides content recommendations to investors based on subscription tier, watchlists, holdings, and engagement history

• Runs first-pass checks on draft content for missing disclosures, unflagged performance claims, hypothetical results, and content types that require compliance review

AI output is never published directly. AI surfaces signals; analysts decide what to do with them. Explanations, summaries, content recommendations, and draft alerts pass through analyst review, compliance approval, and the same Rule 204-2 audit trail as the rest of the platform.

The platform connects to the external systems a U.S. digital advisory business depends on. Every integration uses documented contracts, retries, and circuit breakers, so provider failures degrade gracefully without breaking advisory workflows.

 

Stripe Billing. Manages subscription plans, trials, renewals, upgrades, cancellations, failed-payment recovery, refunds, chargebacks, invoices, and dunning flows. Stripe Elements keeps card data inside Stripe, reducing PCI DSS scope for the platform. Stripe Tax supports state-level sales tax handling where advisory subscriptions are taxable.

 

QuickBooks. Receives Stripe payout and accounting data for revenue reconciliation. Supports subscription revenue by tier, deferred revenue for prepaid annual plans, refund and chargeback categorization, and state-level tax reporting.

 

Salesforce. Stores subscription state, engagement signals, retention workflows, Form ADV Part 2 brochure delivery records, disclosure acknowledgements, and client communication history. Form ADV delivery records are handled under Rule 204-3 workflows, while advisory communications and related records remain part of the Rule 204-2 recordkeeping perimeter.

 

GBG. Supports identity checks during subscriber onboarding — document verification, sanctions screening, and PEP screening where required. The integration gives the firm a CIP-style account verification workflow and supports future AML/CFT readiness without turning the product into a broker-dealer, custody, or trading platform.

 

Polygon.io. Real-time and historical market data for equities, ETFs, options, indices, and digital assets. Used for watchlists, model portfolio analytics, price-movement explanations, alert triggers, and AI-assisted market monitoring.

 

Refinitiv / LSEG Data. Institutional market data, corporate actions, research, and financial news. Analysts use it for research preparation, market commentary, and AI-assisted summarization.

 

Morningstar. Fund and ETF analytics, benchmarks, ratings, and performance data for portfolio analysis and fund comparison.

 

Reuters / MT Newswires. Financial news, earnings events, macro updates, and company-level headlines. Supports analyst research workflows and AI agents that connect market events with portfolio movements and draft alert candidates.

 

Twilio / SendGrid. Twilio for SMS delivery and SendGrid for transactional email, with delivery callbacks captured per-alert and feeding both operational dashboards and Rule 204-2 recordkeeping.

 

Zendesk. Support ticketing and escalation routing, with subscriber timeline data and entitlement state surfaced into the agent view through bidirectional sync.

 

Segment. Server-side product and engagement event collection. Supports onboarding analytics, subscription conversion, content engagement, alert performance, retention analysis, and CRM segmentation while keeping investor PII out of third-party SDKs.

Legacy state

 

The inherited platform looked like a microservices system on paper but behaved like a tightly coupled distributed monolith in production.

 

The main issues were:

• Multiple services wrote to the same MongoDB data store without clear data ownership

• Long synchronous call chains made one timeout fail the whole request processing flow

• Payment webhooks, subscription updates, and alert dispatch were not idempotent

• Services did not share correlation IDs, so incident investigation required manual timestamp matching across logs

• Batch jobs, analytics tasks, and user-facing flows shared infrastructure, so peak load degraded the whole system

New architecture

 

The platform was redesigned on AWS as a properly bounded microservices system: a strongly defined core, clear domain boundaries, and explicit contracts between services.

 

Subscriptions, entitlements, content publishing, advisory communications, and recordkeeping became separate domains with their own data ownership and explicit contracts. High-load areas such as alert dispatch and market data ingestion were gradually extracted behind an anti-corruption layer, allowing the platform to modernize without a big-bang rewrite.

 

Kafka handles asynchronous events between domains. gRPC handles synchronous calls that require typed service contracts. Critical write paths use idempotency keys, so retries are safe and failures do not cascade across domains.

 

Data layer: MongoDB to PostgreSQL

 

Critical data moved from MongoDB to PostgreSQL through phased migrations with dual-write and read-validate stages, with no subscriber-visible disruption. PostgreSQL brought ACID guarantees, versioned schema discipline, and the query performance needed for subscriptions, billing, and SEC/RIA examination support.

 

Payments and subscription state

 

The subscription layer was rebuilt around Stripe Billing and an explicit lifecycle state model.

 

Subscription states — trial, active, past due, paused, cancelled, churned — became exhaustive and controlled. Stripe events are processed idempotently, so redelivered webhooks do not create duplicate access changes, repeated notifications, or inconsistent subscription states.

 

A nightly reconciliation job compares Stripe with the platform’s subscription store and flags drift for operations review. Card data stays inside Stripe Elements, keeping the platform in PCI DSS SAQ-A scope. Stripe payouts reconcile into QuickBooks with revenue recognition by subscription tier and state-level tax handling.

 

Alerts

 

Time-sensitive advisory alerts became a dedicated subsystem.

 

Direct APNs and FCM integrations removed third-party gateways from the critical path. A canonical alert event fans out through Kafka to push, email, SMS, and secondary messaging channels — a delay in one channel does not block the others.

 

Priority queues separate investment alerts from marketing or bulk notifications. Per-channel delivery tracking feeds both operational dashboards and the Rule 204-2 recordkeeping trail. The alert subsystem was load-tested against market-open peak traffic patterns, where concurrent push fan-outs spike sharply.

 

CI/CD, testing, and deployment

 

The delivery process was rebuilt on GitLab CI/CD around three rules: every change is verified before production, every release is reversible, and database changes stay backward-compatible.

 

GitLab CI/CD runs unit, integration, contract, and end-to-end tests on each commit, with dedicated regression coverage for subscriptions, payment webhooks, alert delivery, and recordkeeping. Blue-green deployments, feature flags, and expand-migrate-contract database migrations make releases gradual, reversible, and backward-compatible. Static analysis, dependency checks, secret scanning, and security tests run before merge.

 

Observability and incident response

 

The platform uses Sentry, Grafana dashboards, and centralized logging.

 

Structured logs include correlation IDs across services, so incident investigation starts from one trace instead of manual log matching. Business-level dashboards track subscription health, payment success, alert delivery latency, and audit trail completeness.

 

SLO-based alerts monitor error budget burn rate and surface degradation before subscribers notice it. Runbooks cover common incident classes such as stuck renewals, delayed alerts, failed publications, and audit trail gaps.

 

Reliability and disaster recovery

 

The post-stabilization availability target is 99.95% for unplanned outages — about 22 minutes of monthly downtime budget, compared with about 43 minutes at a standard 99.9% SaaS target.

 

The mechanics behind it:

• Multi-AZ deployment within the primary AWS region

• Load balancer health checks that remove unhealthy nodes from rotation

• PostgreSQL streaming replication with AWS RDS Multi-AZ failover

• Rolling releases and backward-compatible database migrations

• Circuit breakers and timeouts for Stripe, Polygon.io, Refinitiv, APNs/FCM, email, and SMS providers

• Kafka buffering for critical events, so consumer failures do not lose alerts, payment-related events, or audit events

For disaster recovery, the platform uses encrypted backups, point-in-time database recovery, cross-region backup copies, infrastructure-as-code runbooks for environment rebuild, and immutable audit-record storage. The DR target is RPO under 15 minutes and RTO under 1 hour for core advisory flows, supported by warm-standby infrastructure and replicated deployment artifacts in a secondary region. DR procedures are exercised quarterly.

 

Audit trail storage uses S3 Object Lock for WORM-mode retention, supporting Rule 204-2 recordkeeping at the storage layer by making advisory communications, publication approvals, and alert records resistant to accidental deletion or modification.

 

Security and access control

 

Security controls cover role separation, audit logging, PII protection, encrypted traffic, secret management, and hardened public endpoints.

 

RBAC enforces separation of duties — analysts cannot approve their own portfolio updates, reviewers cannot publish content they reviewed. Sensitive actions are logged with full state context. Investor PII is encrypted with AWS KMS and kept out of third-party SDKs. External traffic uses TLS 1.2+, internal calls use mTLS, and credentials live in AWS Secrets Manager.

 

Platform-level audit logs — admin actions, RBAC changes, security events, configuration changes — are retained separately from advisory recordkeeping for a 7-year window aligned with internal audit and SOC 2 requirements. Security controls and operational procedures are designed against SOC 2 Trust Services Criteria for security, availability, and confidentiality, with audit-ready evidence collection built into the observability layer.

 

Mobile apps enforce certificate pinning for API traffic, integrate with Apple App Attest and Google Play Integrity for device attestation, and disable sensitive flows on jailbroken or rooted devices.

Phase 1 — Audit and stabilization roadmap

 

The firm asked Itexus for an independent technical audit, not a takeover. Itexus reviewed the platform end to end, identified the highest-risk areas — production stability, payments, alert delivery, and SEC Rule 204-2 recordkeeping — and produced a roadmap executable either by the incumbent vendor with Itexus guidance or by Itexus directly.

 

The firm initially chose the first option. Itexus provided post-audit guidance to the incumbent team over two months before the firm concluded that the required re-architecture could not be delivered without disrupting production. The full platform — backend, mobile, web, and internal tooling — was then transferred to Itexus.

 

Phase 2 — Stabilization, refactoring, and modernization

 

Phase 2 ran for nine months in two-week Agile iterations, with each release reviewed by the firm’s product, engineering, and compliance leads. The team stabilized production, modernized the critical subsystems, and kept shipping business-priority features without interrupting subscribers.

 

Recordkeeping continuity was a non-negotiable constraint. The Rule 204-2 audit trail remained complete and queryable throughout the migration. Any release touching advisory communications, publishing workflows, or audit storage went through compliance sign-off before deployment.

 

The full engagement ran twelve months from initial audit through stabilization.

 

The platform takeover was completed without subscriber-visible disruption. Paid access, advisory communications, and the Rule 204-2 audit trail remained live and queryable throughout the transition.

 

Post-stabilization availability reached 99.95% for unplanned outages. Release cycles became approximately 30% shorter, and rollbacks shifted from manual database operations to single-click feature-flag toggles. Engineers could trace production issues from a single correlation ID across services, reducing investigation time for stuck renewals, delayed alerts, and payment discrepancies from hours to minutes.

 

The Rule 204-2 audit trail now retains millions of advisory communication records under WORM-mode retention. AI-assisted first-pass review reduced approval time for routine content by approximately 40%, freeing compliance officers to focus on profile-sensitive advisory communications and marketing materials requiring deeper review.

 

Within two months after relaunch, the client reported a 42% increase in paid subscription activity. The platform absorbed that growth without the billing issues, delayed alerts, and production instability that had constrained the previous version.

 

Key outcomes

• Availability: 99.95% post-stabilization uptime for unplanned outages — about 22 minutes monthly, vs. 43 minutes at 99.9% baseline

• Release velocity: ~30% shorter release cycles

• Compliance velocity: ~40% faster first-pass content review through AI-assisted checks

• Growth: 42% increase in paid subscription activity within two months of relaunch

• Scale: 450K+ digital investor community, 100K+ mobile app downloads, millions of recordkept advisory communications

• Compliance posture: Rule 204-2 recordkeeping continuity through platform transfer, exportable for SEC examination

• Operations: Unified billing, entitlements, alerts, support, CRM, accounting, and compliance workflows

The engagement closed with a structured operational handover to the client’s in-house engineering and support teams. Itexus transferred platform knowledge, documentation, support procedures, Infrastructure-as-Code configuration, deployment process, and incident runbooks through a series of workshops.

 

The handover was straightforward because the platform was documented at every level — architecture, API contracts, business logic, Infrastructure-as-Code configuration, deployment process, and standard support procedures. The handover package included examination-readiness materials showing where SEC Rule 204-2 records live, how they are retained, and how to produce them for internal review or SEC examination support, alongside operational runbooks for known incident classes and the quarterly DR exercise schedule.

 

The client’s team now owns production monitoring, incident escalation, release coordination, and routine maintenance. Itexus remains available for product expansion and specialized engineering support on a Time and Materials basis — but the client is no longer dependent on an external vendor to operate or evolve the platform.