Talk to Us +91 98847 45599
HedgePro · Technical Architecture

From positions to exposure management.

HedgePro extends the AlphaSync foundation toward portfolio-level risk analysis, exposure management and hedging workflows.

Architecture preview · In development

Intended logical flow

  1. 01PositionsWhat is open
  2. 02ExposureWhat it adds up to
  3. 03Risk analysisWhere the risk sits
  4. 04Hedge strategyHow it could be reduced
  5. 05ExecutionThrough controlled execution
  6. 06Re-evaluateThe new exposure state
Six stages in a loop: positions, exposure, risk analysis, hedge strategy, execution and re-evaluation of the new exposure. Designed architecture; not every stage is available.

Architecture status

In development
  1. In production. AlphaSync’s risk engine governs each order, with market data, execution, analytics and an audit trail.
  2. In development. HedgePro: exposure, portfolio risk and hedging workflows, built on the AlphaSync foundation.
  3. To be announced. HedgePro availability and its released capabilities.

On this page: Confirmed foundation exists in AlphaSync today. In development is being built. Designed architecture is the intended architecture. Planned is future direction. Illustrative explains a concept, not a feature.

Architecture philosophy

Risk management begins with understanding exposure.

Illustrative

An individual order is only one part of a portfolio. AlphaSync’s risk engine already asks whether each order is allowed: its size, its loss limit, its place within the account’s limits.

As positions accumulate across instruments, strategies, expiries and accounts, the exposure they create together can be more complex than any single order suggests. HedgePro is being designed around that broader question: across everything that is open, what is the exposure, and how should it be hedged?

Figure 1 · From managing orders to managing exposure

  1. OrderOne instruction, checked by the AlphaSync risk engine
  2. PositionWhat the order leaves open
  3. ExposureWhat all open positions add up to
  4. Portfolio riskWhere that exposure is concentrated or sensitive
  5. Hedge decisionWhether and how to reduce it
Five levels, from a single order to a hedge decision. Order-level control exists in AlphaSync today; the levels from exposure to hedge decision are the scope of HedgePro, in development.

Where HedgePro fits

One foundation. A broader view of risk.

Vianmax™’s products share an engineering foundation first built and proven in AlphaSync. Each product uses the parts it needs; a shared foundation is not an identical implementation.

Confirmed foundation In development

Figure 2 · The Vianmax™ product ecosystem

Vianmax™

Shared platform foundationEngineering foundations used where each product needs them

Products

AlphaSyncTrading & execution · In production
AlphaSync CampusLearning & simulation · In development
HedgeProRisk & hedging · In development

Foundation

Market data
Strategy engine
Risk engine
Execution
Analytics
Audit trail
Vianmax™ at the top, a shared platform foundation, and three products: AlphaSync (trading and execution, in production), AlphaSync Campus (learning and simulation, in development) and HedgePro (risk and hedging, in development). The six foundation areas are market data, strategy engine, risk engine, execution, analytics and audit trail.

The existing HedgePro page confirms that HedgePro builds on AlphaSync’s market data, risk engine and analytics layers. Its use of strategy, execution and audit components is designed, not yet built.

HedgePro logical architecture

The intended flow, from market data back to exposure.

The main architecture diagram. It shows logical responsibilities and the order in which they act, not services, servers or a deployment.

Designed architecture

Figure 3 · HedgePro logical architecture

Inputs

Market dataPrices and instrument information

Portfolio state

Position aggregationOrders and fills become portfolio state

Exposure

Exposure engineWhat the portfolio is carrying

Analysis

Scenario analysis
Limits
Concentration

Decision

Hedge engineCandidates and evaluation
Hedge decisionWith review where required

Control

Risk / order checkThe AlphaSync risk engine
ExecutionControlled, through AlphaSync

Feedback

Position update
Exposure recalculationBack to the exposure engine
Seven tiers from top to bottom. Market data feeds position aggregation. Aggregated positions feed the exposure engine. Exposure is analysed through scenario analysis, limits and concentration. The hedge engine produces a hedge decision, which passes the risk and order check and controlled execution. The position update then feeds exposure recalculation, closing the loop.

Architecture shown represents the intended logical flow. Individual capabilities and integrations may change as HedgePro development progresses.

Component explorer

Six components, one responsibility each.

Select a component to see its purpose, inputs, outputs, responsibilities and status. Without JavaScript, all six are listed in full.

Component 01

Market data

Consistent inputs for every calculation.

Confirmed foundation

Market data exists in AlphaSync. Its use by HedgePro is designed.

Purpose
Consistent inputs for every calculation.
Inputs
Market prices, instrument and derivative information
Outputs
Normalised data for downstream risk services
Responsibilities
  • Receive data through controlled interfaces
  • Transform it into consistent structures
  • Reject stale or invalid inputs
Status
Confirmed foundation

Component 02

Position aggregation

See the portfolio as a whole.

Designed architecture

Purpose
See the portfolio as a whole.
Inputs
Orders, fills and positions
Outputs
Portfolio state
Responsibilities
  • Combine fills into positions
  • Group positions into portfolio state
  • Keep state consistent with confirmed execution
Status
Designed architecture

Component 03

Exposure engine

Measure what the portfolio is carrying.

In development

The conceptual heart of HedgePro.

Purpose
Measure what the portfolio is carrying.
Inputs
Portfolio state and market data
Outputs
A risk profile of the portfolio
Responsibilities
  • Measure exposure across positions
  • Express it along analytical dimensions
  • Recalculate as positions change
Status
In development

Component 04

Risk analysis

Turn positions into a risk picture.

Designed architecture

Purpose
Turn positions into a risk picture.
Inputs
The exposure profile
Outputs
Identified risks and their context
Responsibilities
  • Portfolio and position exposure
  • Concentration and limits
  • Scenario behaviour
Status
Designed architecture

Component 05

Hedge engine

From exposure analysis to hedge strategy.

Designed architecture

Purpose
From exposure analysis to hedge strategy.
Inputs
Identified risks and a hedge objective
Outputs
Evaluated hedge candidates and a decision
Responsibilities
  • Form candidates for the objective
  • Evaluate them against scenarios
  • Present a decision for review where required
Status
Designed architecture

Component 06

Execution

A decision connects back to controlled execution.

Confirmed foundation

Execution and risk controls exist in AlphaSync. HedgePro does not place live hedge orders today.

Purpose
A decision connects back to controlled execution.
Inputs
An approved hedge decision
Outputs
Orders, confirmed state and a position update
Responsibilities
  • Validate the order
  • Apply AlphaSync risk controls
  • Update positions from confirmed state
Status
Confirmed foundation

01 · Market data

Reliable inputs before risk calculations.

Confirmed foundation Designed architecture

Exposure analysis is only as good as the data behind it. Market data is designed to enter the platform through controlled interfaces and to be transformed into consistent structures that downstream risk services consume.

AlphaSync already operates a market-data layer in production. HedgePro is designed to build on it. The data sources, instruments and brokers HedgePro will use are not yet defined, and no latency figures are published.

Figure 4 · Potential inputs

  1. Market pricesCurrent and recent prices
  2. Instrument informationContract details and identifiers
  3. Derivative informationStrikes, expiries and contract terms
  4. Position informationWhat is open
  5. Portfolio informationHow positions are grouped
Five potential categories of input: market prices, instrument information, derivative information, position information and portfolio information.

02 · Position aggregation

See the portfolio as a whole.

Individual orders become positions. Positions become portfolio state. Portfolio state becomes the basis for exposure analysis.

Designed architecture

Figure 5 · From orders to exposure

  1. 01OrdersInstructions sent
  2. 02FillsConfirmed executions
  3. 03PositionsWhat is open
  4. 04PortfolioPositions grouped
  5. 05ExposureWhat it adds up to
Five steps: orders, fills, positions, portfolio and exposure. Only confirmed fills are designed to change positions.

Potential aggregation dimensions

Instrument

Positions in the same underlying or contract.

Strategy

Positions opened by the same strategy.

Portfolio

A defined group of positions.

Account

Positions held in one account.

Expiry

Derivative positions sharing an expiry.

Architecture consideration

Which dimensions are supported will be documented when released.

03 · Exposure engine

Measure what the portfolio is actually carrying.

The exposure engine is the conceptual heart of HedgePro: it takes the aggregated portfolio and measures what it adds up to, so that risk can be discussed in terms of exposure rather than individual orders.

In development

Figure 6 · From positions to a risk profile

Portfolio

Position A
Position B
Position C
Position D

Measurement

Exposure engineMeasures the combined exposure

Output

Risk profileExposure along analytical dimensions
Four positions in a portfolio feed the exposure engine, which produces a risk profile of the portfolio as a whole.

Planned analytical dimensions

Directional exposure

Net sensitivity to the direction of the market.

Notional exposure

The size of what is held.

Derivatives exposure

Exposure arising from options and futures.

Concentration

Exposure gathered in one place.

Expiry exposure

Exposure grouped by expiry.

Greek exposure

Option sensitivities such as delta, gamma, vega and theta.

These are potential exposure dimensions for the architecture. None is presented as an available feature, and the calculation methods are not published.

04 · Risk analysis

Turn positions into a risk picture.

Risk analysis is designed to support questions about the exposure profile. It does not produce a risk score, and it is not a regulatory risk calculation.

Designed architecture

Portfolio exposure

The exposure of the portfolio as a whole.

Position exposure

Which positions contribute most.

Concentration

Where exposure is gathered.

Scenario behaviour

How exposure could change under assumptions.

Hedge requirements

Whether exposure exceeds what the user intends to carry.

Limits

Exposure compared with limits the user sets.

05 · Scenario analysis

Understand how exposure could change.

Scenario analysis can help examine how portfolio exposure behaves under different market assumptions. It explores possibilities; it does not predict market direction or guarantee protection.

Designed architecture Illustrative

Figure 7 · Scenario analysis (illustrative)

Start

Current portfolio

Assumptions

Scenario AOne market assumption
Base caseCurrent conditions
Scenario BAnother assumption

Exposure

Exposure A
Exposure B
Exposure C

Hedge need

Hedge need A
Hedge need B
Hedge need C
The current portfolio is evaluated under three assumptions: scenario A, a base case and scenario B. Each produces an exposure, and each exposure suggests a different hedge need.

06 · Hedge engine

From exposure analysis to hedge strategy.

Designed architecture

The hedge engine is designed to turn identified risk into a hedge decision: start from an objective, form candidate hedges, evaluate them against the same scenarios, and arrive at a decision.

This is the intended logical workflow. HedgePro does not place hedge orders today, and the page does not describe any specific hedging algorithm. Where automation is part of the design, it is designed to support controlled execution, not to execute every hedge automatically.

Figure 8 · Hedge workflow

  1. Current portfolioThe portfolio as it stands.
  2. Exposure measurementWhat it is carrying.
  3. Risk identificationWhich exposure is unwanted.
  4. Hedge objectiveWhat the hedge should achieve.
  5. Hedge candidateOne or more ways to reach it.
  6. Scenario evaluationHow each candidate behaves.
  7. Hedge decisionProceed, adjust or do nothing.
Seven steps: the current portfolio, exposure measurement, risk identification, a hedge objective, hedge candidates, scenario evaluation and a hedge decision.

Human review

Automation where appropriate. Human judgement where it matters.

Designed architecture

Risk and hedging decisions often depend on context a system cannot see: intent, constraints and judgement. The architecture is designed so that a hedge proposal can be reviewed and approved by a person before anything is executed.

Not every workflow is intended to require approval, and a proposal is a software output for the user to evaluate. It is not investment advice, and HedgePro is not an investment adviser.

Figure 9 · Review before execution

  1. Hedge analysisExposure and candidates
  2. ProposalA software output
  3. Human reviewContext and judgement
  4. ApprovalWhere the workflow requires it
  5. ExecutionControlled, through AlphaSync
Five steps: hedge analysis, a proposal, human review, approval and controlled execution.

07 · Execution integration

A hedge decision can connect back to controlled execution.

HedgePro is being developed on top of the AlphaSync ecosystem, so a hedge decision is designed to reach the market only through the controls AlphaSync already applies to every order.

Confirmed foundation In development

Figure 10 · From hedge decision to exposure recalculation

HedgePro · in development

Hedge decision

AlphaSync · production foundation

Order validation
Risk controls
Order management
Broker connectivity
Execution

Back to HedgePro

Position update
Exposure recalculation
A hedge decision in HedgePro passes to the AlphaSync production foundation: order validation, risk controls, order management, broker connectivity and execution. The confirmed position update and the exposure recalculation return to HedgePro.

AlphaSync · production foundation

Order validation, risk controls, order management, broker connectivity, executionIn production in AlphaSync today.

HedgePro · in development

Hedge decision, and the position update and exposure recalculation that followHedgePro does not currently execute live hedge orders, and no HedgePro broker support is claimed.

Closed-loop architecture

Hedging is a feedback loop.

A hedge changes the portfolio. The changed portfolio creates a new exposure state. The architecture is therefore designed as a continuous assessment loop rather than a one-time calculation.

Designed architecture

Figure 11 · The hedging feedback loop

  1. 01Market data
  2. 02Positions
  3. 03Exposure
  4. 04Risk analysis
  5. 05Hedge decision
  6. 06Execution
  7. 07Position change

The position change returns to exposure: a new state, assessed again.

Seven stages: market data, positions, exposure, risk analysis, hedge decision, execution and the resulting position change, which returns to exposure for reassessment. How often the loop runs is not specified; it is not described as real time.

AlphaSync foundation

Built on the AlphaSync foundation.

AlphaSync already provides production foundations for market data, strategy, risk, execution, analytics and the audit trail. HedgePro is being developed to extend that foundation toward exposure analysis, portfolio-level risk and hedging workflows. Implementation details of AlphaSync are not assumed to carry over.

Confirmed foundation In development

AlphaSync foundation and HedgePro-specific components
ComponentIn AlphaSyncIn HedgeProRelationship
Market dataProductionDesigned to build on itShared foundation
Strategy engineProductionNot central to HedgeProAlphaSync
Risk engineProduction: order-level controlExtends toward portfolio-level exposureShared foundation, extended
ExecutionProductionDesigned to use for controlled hedge executionShared foundation
AnalyticsProductionDesigned to build on itShared foundation
Audit trailProductionDesigned to record analyses and decisionsShared principle
Position aggregation, exposure engine—In developmentHedgePro-specific
Scenario analysis, hedge engine, human review—DesignedHedgePro-specific

See the AlphaSync architecture for the production foundation.

Platform services

Domain services on shared platform services.

The HedgePro domain services are designed to sit on a set of logical platform services. Not every service is deployed for HedgePro today; configuration applies across all of them.

Designed architecture

Figure 12 · Logical platform services

HedgePro domain services

Risk
Exposure
Hedge

Logical platform services

Auth & RBAC
API
Data
Logging
Monitoring
Audit
Three HedgePro domain services, risk, exposure and hedge, on logical platform services: authentication and role-based access, the API layer, data, logging, monitoring and audit.

Data architecture

A consistent system of record for positions, risk and decisions.

Eight logical data domains. They describe what the system is designed to keep consistent, not a database schema.

Designed architecture

Figure 13 · Logical data domains

Identity

  • Users
  • Roles
  • Permissions

Positions

  • Positions
  • Fills
  • Instruments

Portfolio

  • Portfolios
  • Groupings

Exposure

  • Exposure states
  • Dimensions

Risk

  • Analyses
  • Scenarios
  • Limits

Hedge analysis

  • Objectives
  • Candidates
  • Decisions

Orders

  • Hedge orders
  • Order states

Audit

  • Events
  • Approvals
  • Changes
System of recordTechnology chosen according to platform requirements. Not yet published for HedgePro.
Eight logical domains: identity, positions, portfolio, exposure, risk, hedge analysis, orders and audit, above one system of record whose technology is chosen by platform requirements.

Security architecture

Security surrounds the architecture.

HedgePro is designed to follow the practices on Technology & Security. They are engineering practices, not certifications.

Designed architecture

Identity

Every user and service is identified.

Role-based access

Access follows the role.

Least privilege

Only the access a task needs.

API validation

Every request is validated at the interface.

Secrets management

Credentials stay server-side.

Auditability

Decisions and changes are recorded.

Logging

Services record what they do.

Monitoring

Health is watched while running.

Network controls

Applied according to the deployment.

No ISO, SOC 2 or SEBI certification, completed VAPT or penetration test, specific encryption implementation, uptime or recovery objective is claimed for HedgePro.

Observability

Visible while it runs. Explainable afterwards.

Observability is a published Vianmax™ engineering principle. For HedgePro, the aim is that every analysis and decision can be traced afterwards.

Designed architecture

Figure 14 · Observability pipeline

  1. 01Services
  2. 02Logs
  3. 03Metrics
  4. 04Health
  5. 05Monitoring
  6. 06Alerts
  7. 07Operations
Seven steps: services produce logs, metrics and health signals, which feed monitoring, alerts and operations.

Relevant events, by design

  • Exposure calculation
  • Risk evaluation
  • Hedge analysis
  • Hedge decision
  • Order state
  • Position update

These are the events the architecture is designed to record. Event-level instrumentation for HedgePro is not yet confirmed.

Failure handling

When the state is uncertain, do not guess.

The same philosophy as AlphaSync: stop, report and reconcile rather than act on uncertain state. This is designed behaviour. No system can promise zero downtime, and automatic recovery is not claimed.

Designed architecture

Designed failure handling in HedgePro
FailureDetectionResponseOutcome
Market data failureMissing, stale or invalid dataStop calculating on the affected data; show the userNo analysis presented on bad inputs
Position data inconsistencyPositions that do not reconcileFlag the inconsistency; reconcile before continuingExposure shown only on reconciled state
Broker connectivity failureRejected or unanswered requestStop and report through AlphaSync controlsNo assumed execution state
Order-state uncertaintyStatus not confirmedTreat as unknown until confirmedPositions updated only from confirmed state
Database failureFailed writes or health checkRecovery according to the documented procedureState restored consistently, with an audit record
Service failureHealth checkIsolate the failing serviceOther services unaffected where possible
Network failureLost connectionStop, report, then a controlled reconnectionResume only on confirmed state

Resilience principles

Six rules for uncertain moments.

Architectural principles for HedgePro. They are the design intent, not a description of implemented behaviour.

Designed architecture

  1. 01Do not act on stale or invalid inputsAn analysis is only as current as its data.
  2. 02Do not assume an unconfirmed execution statePositions change only on confirmed fills.
  3. 03Preserve an audit trailEvery analysis, decision and change can be traced.
  4. 04Isolate failures where possibleOne failing service should not stop the rest.
  5. 05Reconcile state before continuingResume only on reconciled positions.
  6. 06Prefer controlled recovery over blind retriesRetry only when it is safe to.

Deployment model

From reviewed code to monitored services.

A high-level model only. No hosting provider, region, cluster, container topology or network detail is published.

Illustrative

Figure 15 · High-level deployment model

  1. DeveloperChanges are written and reviewed.
  2. Source controlEvery change is versioned.
  3. Build & testChanges are built and tested before release.
  4. Deployment environmentA separate environment for each stage.
  5. HedgePro servicesThe domain services.
  6. Data & integration servicesData and the AlphaSync foundation.
  7. MonitoringHealth from the moment services start.
Seven steps: developer, source control, build and test, deployment environment, HedgePro services, data and integration services, and monitoring.

Actual hosting, infrastructure and deployment configuration may vary by environment and product release.

Architecture layers

Seven layers, each with one job.

The same layered discipline as AlphaSync, applied to exposure and hedging. L5 and L7 build on foundations that exist in AlphaSync today; the rest are HedgePro layers in development or design.

L1PresentationHow users see exposure and decisions
  • Exposure views
  • Decision review
Planned
L2API / applicationEvery client request enters here
  • Validated interfaces
  • Access control
Designed architecture
L3Risk & exposure intelligenceWhere exposure is measured and analysed
  • Position aggregation
  • Exposure engine
  • Risk and scenario analysis
In development
L4Hedge decisionFrom objective to decision
  • Hedge candidates
  • Evaluation
  • Human review
Designed architecture
L5Execution integrationDecisions reach the market only through AlphaSync controls
  • Order validation
  • Risk controls
  • Execution
Confirmed foundation
L6DataThe logical system of record
  • Positions
  • Exposure
  • Decisions
  • Audit
Designed architecture
L7Platform / infrastructureWhat every layer depends on
  • Identity
  • Logging
  • Monitoring
  • Configuration
Confirmed foundation

Technical design principles

Ten principles behind HedgePro.

Engineering principles that guide the architecture, not claims about implemented features.

01 · Modular architecture

Each component can change without rewriting the others.

02 · Separation of concerns

Measuring, analysing, deciding and executing stay apart.

03 · Security by design

Controls are part of the design, not added later.

04 · Least-privilege access

Every role and service gets only what it needs.

05 · Observable services

Every analysis and decision can be traced.

06 · Controlled execution

Hedges reach the market only through risk controls.

07 · Data integrity

Exposure is calculated only from reconciled state.

08 · Failure isolation

One failure should not become many.

09 · Auditability

Decisions and changes are recorded.

10 · Extensibility

New analytical dimensions can be added as the product evolves.

AlphaSync and HedgePro

Complementary products, different questions.

Not a comparison of which is better: each answers a different question within the Vianmax™ ecosystem.

In production

AlphaSync

Focus: trading strategy and execution. Is this order allowed, and how is it executed?

  1. Idea
  2. Strategy
  3. Risk
  4. Order
  5. Execution
  6. Analytics
AlphaSync architecture

In development

HedgePro

Focus: risk and exposure management. Across everything that is open, what is the exposure, and how should it be hedged?

  1. Positions
  2. Exposure
  3. Risk
  4. Hedge analysis
  5. Hedge decision
  6. Execution
  7. Reassessment
HedgePro overview

Product ecosystem

Three products on one foundation.

Figure 16 · The Vianmax™ product ecosystem

Vianmax™

Shared foundation

Products

AlphaSyncTrading & execution
CampusLearning & simulation
HedgeProRisk & hedging

Market data · Strategy · Risk · Execution · Analytics · Audit

Three products, AlphaSync, AlphaSync Campus and HedgePro, on one shared foundation of market data, strategy, risk, execution, analytics and audit.

See the product ecosystem.

Architecture note. HedgePro is currently in development. This page describes the intended logical architecture and engineering direction, not a guarantee of released functionality. Capabilities, integrations, deployment configurations and implementation details may change as development progresses. The diagrams are logical representations and should not be interpreted as a complete physical deployment topology.

Important. HedgePro is risk and hedging software technology. It is not investment advice or portfolio management, and it does not guarantee risk protection, hedging outcomes or returns. Vianmax™ is not a SEBI-registered investment adviser, research analyst or stock broker. Trading in securities and derivatives involves risk.

Managing derivatives exposure?

Tell us what you need from risk and hedging technology. We will share where HedgePro stands.

info@vianmax.com+91 98847 45599