fsi-capital-oms

Files (6)

• SKILL.md
• SKILL_ja.md
• multiaz-architecture.png · assets/images/
• outposts-architecture.png · assets/images/
• reference-architecture.png · assets/images/
• architecture.md · references/

SKILL.md (first lines)

# FSI Capital Market OMS (資本市場 OMS)

## Workload Overview

This is a **case study** (not a deployable reference implementation) describing a cloud-native
architecture for a securities firm's **Order Management System (OMS)** — the core system that
sits in the **front-to-middle** layer of a brokerage's system landscape. The design is modeled on
real OMS architectures currently running in domestic and overseas securities firms, and is shaped to
meet the latency and availability requirements those firms demand.

**Scenario.** The OMS accepts orders from retail investors, institutional investors, and traders,
manages fills, and places orders to exchanges. It also delivers real-time market information
(price movements, quotes) received from information vendors to investors. During trading hours the
front-to-middle system performs real-time processing of customer orders and provisional
add/subtract of positions, balances, and buying power. A separate **back-office system** — outside
this OMS scope — receives and processes final settlement data from exchanges and clearing houses
after the market closes, computes confirmed values, and transfers that confirmed data to the
front-to-middle system via **overnight batch** so it can be refreshed before the next business day.

**Purpose and significance.** Brokerage OMSs face a **trilemma of latency, scalability, and high
availability**. Historically each firm developed its own OMS and maintained it on-premises for a
long time; large systems still commonly run on mainframes. The purpose of this reference
architecture is to provide guidance for a cloud-native OMS that achieves the optimal balance across
that trilemma according to each firm's diversifying needs.

**Business drivers / challenges.** Recent sharp growth in trading volume drives expectations for
cloud adoption to enable flexible capacity adjustment and cost optimization of the
order-receipt/placement system. Three challenges are called out:

- **Latency requirement.** To minimize price slippage between order acceptance and execution and to
  raise the probability of filling at the best quote, extremely low latency is required. Firms
  traditionally used exchange colocation services or same-datacenter placement, but as products and
  investor services diversify, uniformly spending large cost to prioritize latency above all else no
  longer always has the best return on investment.
- **Scalability.** Continuously increasing trading volume and unpredictable sharp peaks during market
  events widen the gap between required capacity at peak versus normal times, making the cost of
  securing peak-handling resources a challenge.
- **High availability.** As securities trading grows in importance as social infrastructure, the
  availability requirement for the OMS — the center of the trade lifecycle — is becoming ever more
  stringent.

**Real cloud-native OMS references cited by the case study:** Vanguard critical trading platform;
Fidelity Asset Management's Equity Trading Platform; Santander trading platform. (Public case links
are collected in `references/architecture.md`.)

For an architecture that runs the EMS (Execution Management System) together on AWS Outposts, the
case study points to the BLEA for FSI **Hybrid** securities-trading system reference architecture.

## Best Practices and Key Components

### Best Practices

- MUST: Separate the "order receipt & fill" (受注・約定) processing from the "order placement &
  execution result" (発注・出来) processing, and connect the two through an asynchronous messaging
  tier — this decoupling lets each layer scale independently, keeps consistency within each layer,
  and lets firms swap the messaging backbone to fit their needs.
- SHOULD: Place the "order placement & execution result" processing close to the EMS (Execution
  Management System) that routes orders to exchanges, to minimize exchange-communication latency.
- PREFER: When extremely low latency is required, disable cross-AZ communication and complete all
  processing within a single AZ using an AZ-level Active/Standby architecture; when the latency
  requirement is relaxed, the same architecture can be configured as a cross-AZ Active/Active
  multi-AZ deployment.
- SHOULD: Enable AWS Auto Zone Shift so that when an AZ fails, traffic is automatically shifted away
  from the affected AZ — it is recommended for both the Active/Standby (cross-AZ disabled) and the
  Active/Active (cross-AZ allowed) configurations to quickly detach a failing AZ.
- MUST: For services not directly supported by Auto Zone Shift (as of 2025/08, Amazon ECS and Amazon
  ElastiCache for Redis), implement custom failover using an Auto Zone Shift start-event notification
  delivered via Amazon EventBridge and orchestrated with AWS Step Functions and AWS Lambda.
- SHOULD: Combine reactive load-based autoscaling with scheduled scaling — e.g. predict opening-auction
  order volume and scale out before the market opens — because the reaction speed of load-based
  scaling alone is a limitation against sudden bursts.
- SHOULD: For OMS-to-back-office data linkage (positions/balances, customer master, credit info,
  fee/tax calculation results), use managed services — Amazon S3 as the data-exchange relay point,
  AWS Step Functions for workflow control, and AWS Lambda for execution — to gain scalability and
  reduce operational load in the overnight batch (ingest, consistency verification, refresh).
- PREFER: For mission-critical DR, adopt a multi-region configuration; use Aurora cross-region
  replication to avoid data loss, but note messaging-tier data needs separate loss-pattern protection.
- SHOULD: Plan the DR switchover as a deliberate, largely manual process (re-establishing exchange
  connectivity, verifying back-office data consistency), reserving a realistic window of several hours
  to about one business day and choosing timing that minimizes business impact.
- MAY: Consider AWS Outposts placed near the exchange or in a colocation center to minimize
  FIX-protocol communication delay to the exchange; a single Outposts is the base configuration, and
  multiple Outposts can be considered for higher availability at the cost of added data-consistency
  work.
- MUST NOT: Assume the Auto-Zone-Shift custom-failover implementation for out-of-scope services will
  work during an AWS control-plane outage — it depends on the AWS control plane and may not function
  then.
- WILL: The architecture uses containerized microservices on Amazon ECS because the front (order
  receipt) and execution/exchange-facing processing have different load characteristics and different
  business-logic change frequencies.
- WILL: The loosely-coupled, messaging-connected component design lets the messaging backbone be
  chosen or swapped flexibly — Amazon MSK when long message retention or many consumer groups are
  needed, or Amazon SQS when ordering matters less and simple queueing suffices.

### Key Components

#### Order Receipt & Fill (Front) Microservice

- **Component Overview**: Accepts orders from retail investors, institutional investors, and traders,
  and manages fills. Runs as a container-based microservice because its load characteristics and
  business-logic change frequency differ from the execution side; it can scale independently.
- **Assumed AWS Services**: Amazon Elastic Container Service (ECS)

#### Order Placement & Execution-Result (Execution) Microservice

- **Component Overview**: Handles order placement to and execution results from exchanges, positioned
  logically close to the EMS to minimize exchange-communication latency. Can be relocated onto AWS
  Outposts near the exchange for the lowest latency. Scales independently from the front layer.
- **Assumed AWS Services**: Amazon Elastic Container Service (ECS); optionally AWS Outposts

#### Low-Latency Messaging Backbone

- **Component Overview**: Asynchronous messaging tier connecting the "order receipt & fill" and
  "order placement & execution result" layers. Uses in-memory Redis Streams for high-speed, low-latency
  processing with simple operations. The component is swappable: MSK for long retention / many
  consumer groups, or SQS for simple queueing where ordering is less important.
- **Assumed AWS Services**: Amazon ElastiCache for Redis (Redis Streams); alternatives Amazon MSK,
  Amazon SQS

From aws-samples/sample-fsi-reference-architecture-jp, MIT-0.

More from aws-samples/sample-fsi-reference-architecture-jp