Run your fintech's back office from your Rails app

01 · the stakes

The bar an admin has to clear when money moves through it

When your product moves money, the internal tool is where the risky clicks happen. An admin that was fine for a CRUD app becomes the most scrutinized surface in your stack.

• 01

  Every change needs a paper trail

  Who raised that limit, who approved that KYC check, who issued that refund and why. When an auditor or a partner bank asks, "we're not sure" is not an answer, and bolting logging onto a hand-built admin after the fact is a project nobody schedules.

• 02

  Support touches money, so access has to be narrow

  The person answering tickets should be able to issue a refund without also being able to edit balances or see full account numbers. An all-or-nothing admin login is a finding waiting to happen.

• 03

  Your data cannot transit someone else's servers

  A hosted admin builder puts a vendor between your team and your financial data, and that vendor becomes a line item in every security review. Inside a regulated stack, the tool has to live where the data lives.

• 04

  Review queues rot when engineers own them

  Pending KYC checks, disputed charges, and flagged accounts pile up when every action needs a developer to run a console command. The queue is an ops job; the tooling for it should not be an engineering backlog.

02 · the Avo version

Your models are already the hard part. Avo is the rest.

Avo mounts inside your Rails app as an engine, so accounts, transactions, and KYC records stay in your database and never sync out to a vendor. You point resources at the models you already have, enforce access with the Pundit policies your app already uses, and turn the money verbs into actions your team runs instead of console commands an engineer runs.

A Transaction resource with a refund action and masked fields:

class Avo::Resources::Transaction < Avo::BaseResource
  self.includes = [:account]

  def fields
    field :reference, as: :text, readonly: true
    field :amount, as: :number, readonly: true
    field :status, as: :select, enum: ::Transaction.statuses
    field :card_number, as: :text, visible: -> { current_user.compliance? }
    field :account, as: :belongs_to
  end

  def actions
    action Avo::Actions::RefundTransaction
  end
end

class Avo::Actions::RefundTransaction < Avo::BaseAction
  self.name = "Refund transaction"
  self.confirm_button_label = "Issue refund"

  def fields
    field :reason, as: :textarea, required: true
  end

  def handle(query:, fields:, current_user:, **)
    query.each { |txn| txn.refund!(reason: fields[:reason], by: current_user) }
    succeed "Refunded #{query.count} transaction(s)"
  end
end

03 · the timeline

From first resource to the team running on it

case study · cybersecurity platform

04 · start today

Give your ops team the back office this week

Avo is per app with unlimited users, so the whole team works from it without the bill scaling with headcount. When you hit an edge Avo doesn't cover, you drop to plain Rails instead of filing a feature request.

Things fintech teams build with Avo

Avo by industry

Avo for your team