Building a Securities Brokerage with Ruby and Go

December 31, 2025

How Bloomo built a regulated trading system from scratch

By Satoshi Kobayashi (noel), CTO – Bloomo Securities RubyWorld Conference 2025 – Day 1

Introduction

At RubyWorld Conference 2025, Satoshi Kobayashi (小林悟史 / noel), CTO of Bloomo Securities Inc., delivered one of the most consequential Ruby case studies in recent years:

“Building a Securities System from Scratch with Ruby and Go – What Worked, What Hurt, and What We Learned.”

Bloomo is not a fintech demo. It is a licensed Japanese securities broker that allows customers to invest in US stocks and ETFs, automatically execute trades, and manage diversified portfolios.

What makes this story extraordinary is not just the product — it is that Bloomo’s core production system is built on Ruby on Rails and Go, running on Kubernetes in Google Cloud, and trusted with real customer money.

Bloomo: A Ruby-born securities company

Bloomo provides a mobile app where users:

• Build or copy investment portfolios
• Invest in US stocks and ETFs
• Automatically rebalance and reinvest dividends
• Let Bloomo execute all trades on their behalf

Over 90% of users begin by copying portfolios, lowering the barrier to serious investing.

The company itself was born from Ruby community meetups, not a bank or accelerator — an important reminder of how powerful developer communities can be.

The core architectural rule

From day one, Bloomo defined a single rule that drives its entire system:

“We separate systems based on whether they touch customer money.”

This leads to a strict split:

DomainTechnologyAPIs, users, admin, identity, validationRuby on RailsTrading, portfolios, money, settlementGo

This boundary dramatically simplifies security, reasoning, and deployment.

Why Ruby on Rails was chosen

Rails was selected for everything except money movement because:

• It provides ORM, migrations, authentication, and testing out of the box
• It is excellent for fast-changing business and admin interfaces
• There is a large pool of Rails engineers
• Security primitives are mature

What Ruby on Rails actually does

1. Account creation & identity

Rails manages:

• Name, address, identity data
• eKYC integration
• Consent flows
• Encrypted storage of personal data

Bloomo uses attr_encrypted instead of Rails’ default encryption to ensure per-record keys, increasing breach resistance.

Example:

class Customer < ApplicationRecord
  attr_encrypted :full_name, key: :encryption_key
  attr_encrypted :address, key: :encryption_key

  before_create do
    self.encryption_key = SecureRandom.hex(32)
  end
end

This means every customer record has its own cryptographic key.

2. Authentication gateway

Rails sits in front of Go and acts as a security gateway.

Originally implemented with Devise, it was later migrated to Firebase Authentication to enable two-factor authentication during waves of brokerage account hijacking.

Example gateway flow:

class Api::GatewayController < ApplicationController
  before_action :authenticate_user!

  def forward
    payload = normalize_params(params)
    GoTradingClient.call(payload, current_user.id)
  end
end 

Go services never see unauthenticated traffic.

3. Securities operations & admin

Rails provides:

• Account approval
• Trade monitoring
• Compliance document management
• Maintenance mode
• Feature flags
• Forced client updates

Bloomo uses motor-admin-rails for a highly customizable admin UI.

Background jobs (reconciliation, imports, reporting) are run via Sidekiq.

Why Go was chosen for money

Go handles:

• Portfolio calculations
• Buy / sell orders
• Rebalancing
• Dividend reinvestment
• Trade settlement
• Cash reconciliation
• Communication with Alpaca Securities (US broker)

The system is optimized for correctness, not raw speed.

How Bloomo keeps money safe in Go

Idempotent APIs

The same request must never be processed twice.

func PlaceOrder(req OrderRequest) error {
  if IsProcessed(req.IdempotencyKey) {
    return nil
  }
  return processAndRecord(req)
}

Database row locking

Any money-changing operation locks the source record first.

SELECT * FROM accounts
WHERE id = $1
FOR UPDATE;

This prevents race conditions in high-value operations.

Consistency verification

Bloomo runs batch jobs that re-validate:

• Asset totals
• Portfolio weights
• Cash balances

These run in Kubernetes-managed jobs.

What worked

Bloomo reports:

• Clean separation of responsibility
• Independent deployment of Rails and Go
• Lower cognitive load for engineers
• Strong technical diversity inside the team

What was hard

They faced real production pain:

• Complex integration testing
• Monitoring across two languages
• Hiring and training cost
• Data duplication between systems (technical debt)

How they mitigated it

They invested heavily in:

• End-to-end testing from account creation to trade execution
• Observability using OpenTelemetry, Sentry, SLI/SLO dashboards
• Team design: teams are built around customer problems, not languages
• Continuous refactoring to remove duplicated data over time

Why this matters for Ruby

Bloomo proves something critical:

Ruby on Rails is trusted with identity, compliance, security, and operational control inside a regulated securities broker.

This is Ruby running at the heart of a financial institution.

Not as a side tool — but as the gateway that protects real money.

Final thoughts

Bloomo’s story is not about hype or heroics. It is about:

• Clear system boundaries
• Conservative engineering
• Respect for money
• Long-term architectural thinking

And Ruby plays a central role in making that possible.