D.1 Compatibility & Business-Value Matrix

This section provides a comprehensive analysis of module compatibility and business value to help brokers make informed decisions about their SSO (OAuth) implementation strategy. The matrix outlines which modules can be combined, their business benefits, and deployment considerations.

Module Compatibility Overview

Identity Module Requirements

Feature Module	B.1 — Full SSO	B.2 — Light Identity Handoff	Key Business Difference
∅ Identity only (without C.*)	✅ Minimum Auth. Branding, CRM as identity owner, unified credentials, auto re-login. Critical for brokers needing control over first page and identity posture: WL brokers, regulated jurisdictions, mature CRM planning phased expansion to C.* modules.	✗ This identity type only has business meaning when combined with at least one identity-agnostic feature module (C.2, C.3, C.4). No standalone business value.	—

Feature Module Compatibility

Feature Module	B.1 — Full SSO	B.2 — Light Identity Handoff	Business Value Difference
C.1 · Embedded cTrader Web	✅ cTrader Web inside CRM. One login → one-click cTrader Web in iframe CRM, no repeat login. Removes switching barrier, increases engagement and retention. Natural for brokers where cTrader Web is main channel and CRM is main UX hub.	✗ C.1 requires long-term accessToken; B.2 doesn't provide this.	—
C.2 · InApp Deposit/Withdraw	✅ Depositing in branded cTrader. Cashier embedded in cTrader under broker brand, identity end-to-end on broker side. Full vertical integration Cashier + login; usually part of complex rebrended client area.	✅ Depositing as lightweight add-on. "Deposit" button in cTrader opens broker Cashier via one-time token. Spotware remains identity provider, login unchanged. Minimal integration cost; ideal for testing "Cashier-in-click increases deposit" hypothesis and brokers without full CRM.	B.1 — vertical integration (brand + identity + Cashier in single canvas); B.2 — point UX-uplift without architectural commitment. Difference in commitment level and who owns identity data.
C.3 · InApp KYC	✅ KYC in unified broker identity. KYC flow embedded in cTrader, managed by broker; identity owned by broker → unified compliance audit trail, simple re-KYC. Appropriate for regulated brokers with high re-verification frequency and strict KYC data storage requirements.	✅ KYC as ad-hoc compliance gate. KYC page opens on demand (before deposit, withdrawal, exceeding trading limit) as modal in cTrader. Broker doesn't intervene in login but imposes compliance barrier when needed. Suitable for brokers where KYC is rare or outsourced to third-party (Jumio, Sumsub).	B.1 — KYC as part of regulated broker identity, full audit; B.2 — KYC as event-gate over foreign identity, less responsibility for identity but also less control over compliance context.
C.4 · InApp Generic / Chat	✅ Support in branded ecosystem. Chat history and support context tied to broker-owned identity; full support experience assimilation into brand. Appropriate for brokers building long-term relationships and making support part of product differentiation.	✅ Chat/Generic as lightweight add-on. "Chat with support" (or any generic link) opens broker page with one-time token authorization. Cheap way to add support channel to cTrader without identity redesign. Naturally overlays existing toolset (Intercom, Zendesk, custom helpdesk).	B.1 — full support integration into brand ecosystem; B.2 — existing support toolset authorization over foreign identity. Difference in UX assimilation depth and interaction history ownership.
C.5 · InApp Controls / Ribbons	✅ Managed plaques inside cTrader. Broker shows targeted promos, reminders, action buttons to specific user segments (bound to userId). Ribbons — marketing and retention tool: cross-sell, upsell, reactivation of sleeping clients. Full control because broker through B.1 already owns userId directory of their users.	✗ Without B.1, broker has no userId directory for targeted ribbons; broker-wide ribbons lose marketing value.	—
C.6 · Partner / Invite / Trader Attribution	✅ Full affiliate program. New user from referral link gets partnerId bound to userId at creation (B.1 steps 12-15). End-to-end attribution, payout workflow, multi-level IB tree. Central monetization lever for IB-heavy brokers.	✗ partnerId bound at user creation (B.1) which doesn't exist in B.2; post-hoc via §3.6 loses "attribute at signup" semantics.	—

Deployment Scenarios Analysis

Identity-Only Deployments

B.1 Full SSO Only

Business Case:

• Target: Regulated brokers, white labels, brokers with mature CRM
• Value: Complete brand control, unified identity, compliance ownership
• Use Case: Brokers needing to own customer identity and compliance

Requirements:

• OAuth-capable CRM system
• Strong compliance framework
• Brand consistency requirements
• Long-term customer relationship strategy

B.2 Light Identity Only

Business Case:

• Target: Quick deployment, testing integration, legacy systems
• Value: Minimal integration cost, fast time-to-market
• Use Case: Brokers testing SSO waters or with limited technical resources

Limitations:

• No standalone business value
• Must be combined with feature modules
• Limited identity control
• Reduced branding opportunities

Feature-Driven Deployments

C.2 InApp Deposit/Withdraw

B.1 Full SSO + C.2:

• Value: Vertical integration of cashier and identity
• Target: Brokers with existing payment infrastructure
• Benefits: Full brand control, unified user experience

B.2 Light Identity + C.2:

• Value: Point solution for deposit optimization
• Target: Brokers testing deposit conversion improvements
• Benefits: Minimal integration, quick deployment

C.3 InApp KYC

B.1 Full SSO + C.3:

• Value: Unified compliance framework
• Target: Regulated brokers with strict KYC requirements
• Benefits: Complete audit trail, simplified re-KYC

B.2 Light Identity + C.3:

• Value: Event-driven KYC integration
• Target: Brokers with outsourced KYC solutions
• Benefits: Compliance gates without identity overhaul

Strategic Decision Framework

Business Priority Assessment

High Priority Scenarios

1. Regulated Compliance Requirements

   • Recommended: B.1 + C.3 (KYC) + additional modules
   • Rationale: Complete control over compliance audit trail

2. Brand-Centric Strategy

   • Recommended: B.1 + multiple C.* modules
   • Rationale: Complete brand ownership across user journey

3. Quick Market Entry

   • Recommended: B.2 + C.2 (Deposits) or C.4 (Chat)
   • Rationale: Minimal integration, fast deployment

Medium Priority Scenarios

1. Gradual Migration

   • Recommended: Start with B.2 + C.2, migrate to B.1
   • Rationale: Test integration before full commitment

2. Feature-Specific Needs

   • Recommended: B.2 + specific C.* module
   • Rationale: Address specific business need

Low Priority Scenarios

1. Identity-Only Deployments
   • Recommended: Only if planning future feature expansion
   • Rationale: Limited standalone value

Technical Capability Assessment

Advanced Technical Teams

• Recommended: B.1 Full SSO
• Benefits: Maximum flexibility, complete control
• Requirements: OAuth implementation, strong technical resources

Limited Technical Resources

• Recommended: B.2 Light Identity
• Benefits: Simpler implementation, faster deployment
• Requirements: Basic API integration capabilities

Legacy Systems

• Recommended: B.2 Light Identity
• Benefits: Minimal system changes
• Requirements: API endpoint availability

Business Value Quantification

Revenue Impact Analysis

High Impact Modules

1. C.2 InApp Deposit/Withdraw

   • Expected Conversion Increase: 15-25%
   • Revenue Impact: High
   • Implementation Complexity: Medium

2. C.6 Partner/Attraction

   • Expected User Acquisition: 20-30% increase
   • Revenue Impact: High
   • Implementation Complexity: High

Medium Impact Modules

1. C.1 Embedded cTrader Web

   • Expected Engagement Increase: 10-20%
   • Revenue Impact: Medium
   • Implementation Complexity: Medium

2. C.5 InApp Controls/Ribbons

   • Expected Conversion Increase: 5-15%
   • Revenue Impact: Medium
   • Implementation Complexity: Low

Low Impact Modules

1. C.3 InApp KYC

   • Expected Compliance Improvement: Significant
   • Revenue Impact: Indirect
   • Implementation Complexity: Medium

2. C.4 InApp Generic/Chat

   • Expected Satisfaction Increase: 10-15%
   • Revenue Impact: Low
   • Implementation Complexity: Low

Cost-Benefit Analysis

Implementation Costs

• B.1 Full SSO: High initial cost, low long-term maintenance
• B.2 Light Identity: Low initial cost, moderate long-term costs
• C. Modules*: Variable complexity and costs

Operational Benefits

• Support Efficiency: Reduced support tickets
• User Retention: Improved user experience
• Compliance Costs: Streamlined compliance processes
• Marketing ROI: Better conversion rates

Migration Paths

From B.2 to B.1

1. Phase 1: Deploy B.2 + selected C.* modules
2. Phase 2: Develop OAuth capabilities in CRM
3. Phase 3: Migrate to B.1 while maintaining C.* modules
4. Phase 4: Expand C.* module deployment

Modular Expansion

1. Start: B.1 or B.2 + one C.* module
2. Expand: Add additional C.* modules based on business priorities
3. Optimize: Refine and optimize based on performance data
4. Scale: Scale deployment across user base

Risk Assessment

Technical Risks

• Integration Complexity: Higher with B.1 Full SSO
• System Dependencies: More dependencies with full integration
• Migration Risk: Risk during migration from B.2 to B.1

Business Risks

• User Adoption: Risk of user resistance to new flows
• Brand Dilution: Risk with B.2 limited branding
• Compliance Gaps: Risk of incomplete compliance coverage

Mitigation Strategies

• Phased Deployment: Reduce risk through gradual implementation
• User Education: Minimize adoption resistance through education
• Testing: Comprehensive testing before full deployment
• Fallback Plans: Maintain fallback options during transition

This compatibility and business value matrix provides brokers with the analytical framework needed to make informed decisions about their SSO (OAuth) implementation strategy, balancing technical capabilities with business objectives.