Skip to content
Introducing Managed AI: governed AI for financial servicesLearn more →
Services · Development

Data platforms, reporting, and internal applications.

Transform disconnected systems and spreadsheets into a unified reporting and application environment. With custom development, process automation, and ongoing support, your team gains the tools needed to work more efficiently.

06

One warehouse, modelled in dbt, run by the team that built it.

The usual starting point is a NAV file from the administrator, a position export from the OMS, a Bloomberg pull, and an Excel workbook that reconciles them by hand every month. We land those feeds in Snowflake or Databricks, model them in dbt with tests and lineage, and report from that one layer. Then we keep running it, which is the part that separates this from a consultancy engagement.

What's included

  • Warehouse build on Snowflake or Databricks
  • dbt modelling, testing & documentation
  • Reporting in Power BI, Tableau & Excel
  • Custom applications on Postgres
The data platform

A dozen feeds in. One set of numbers out.

The warehouse work is the foundation everything else on this page stands on. This is the whole path, from the vendor feed to the number in an investor report.

Feeds in

Fivetran, Airbyte, or Python — landed raw, with load timestamps

Fund administrator

NAV, investor records

Citco, SS&C, Apex

Custodians & PB

Positions, cash

SWIFT, MT535, SFTP

OMS / PMS / EMS

Orders, fills, P&L

Enfusion, Geneva, Eze

Market data

Prices, reference

Bloomberg, ICE, LSEG

CRM & IR

Investors, pipeline

Salesforce, Dynamics

Accounting & AP

GL, expenses

NetSuite, Bill.com

Treasury & banking

Balances, wires

Bank portals

Spreadsheets

The ones still in use

SharePoint

dbt on Snowflake or Databricks

Git, reviewed on PRdbt Cloud or Airflow

Transformation you can read, test, and roll back.

The modelling layer is SQL in a dbt project, in Git, built in three stages. No stored procedures nobody can account for, and no spreadsheet doing load-bearing work in the middle of a reporting chain.

01

staging

One model per source table. Renamed, typed, lightly cleaned, and nothing else — so a change at the vendor lands in exactly one place.

stg_geneva__positions

02

intermediate

The joins and reshaping that carry business logic: position to instrument, trade to strategy, investor to vehicle.

int_positions_enriched

03

marts

The tables people actually query. Exposure, P&L, investor balances, fee accruals — each one documented and tested.

fct_exposure_daily

Tested
Uniqueness, not-null, referential and business-rule tests run on every build.
Documented
Column-level descriptions generated from the project, not maintained by hand.
Lineage
Every figure traceable to the source feed and the transformation that produced it.
Owned
A named owner and a freshness expectation per model, monitored and alerted.

Out to

one modelled layer, every consumer

Dashboards & BI

Power BI, Tableau

Investor & LP reporting

Packs, on the calendar

Regulatory returns

Form PF, Annex IV

AI agents

Claude, Bedrock

Custom applications

Next.js on Postgres

12

Source systems

landed raw

180

dbt models

staging → marts

340

Automated tests

every build

06:00

Refresh complete

before the desk opens

Figures describe the shape of a typical mid-size fund build and are illustrative, not a measured average across clients.

What we build

Four practices, and what each hands over.

01

Data platform & warehousing

Feeds land in Snowflake or Databricks through Fivetran, Airbyte, or Python jobs where no connector exists. dbt models them in staging, intermediate, and mart layers with tests on every build, orchestrated in dbt Cloud or Airflow so the marts are current before the desk opens.

Delivered

  • Warehouse build on Snowflake or Databricks
  • Ingestion via Fivetran, Airbyte, or Python
  • dbt project with tests and generated docs
  • Orchestration and freshness alerting
02

Analytics & reporting

Power BI, Tableau, and Excel pointed at the same modelled tables, so the exposure number on the desk dashboard and the one in the LP pack come from the same dbt model. Regulatory returns are built as datasets rather than assembled by hand each cycle.

Delivered

  • Semantic model in Power BI or Tableau
  • Live Excel connections to the warehouse
  • Investor, LP, and IC pack automation
  • Form PF, AIFMD, and Annex IV datasets
03

AI, agents & automation

Claude via the Anthropic API or Amazon Bedrock, reading from the governed layer rather than from a folder of PDFs. Diligence and subscription document extraction, reconciliation break triage, research summarization, each with an evaluation set so you can see where it fails.

Delivered

  • Document extraction on Claude or Azure AI
  • Reconciliation break triage agents
  • Retrieval over the modelled warehouse
  • Evaluation harness per use case
04

Custom applications

Next.js and TypeScript on Postgres, deployed to Azure App Service or Container Apps inside the tenancy RFA already runs. Investor portals, allocation and approval workflows, and the operational tools your team currently keeps in a shared spreadsheet.

Delivered

  • Investor & client portals
  • Internal workflow tooling
  • Integrations against vendor APIs
  • Hosting, monitoring & service desk
The stack

We will tell you what it runs on.

Snowflake or Databricks for the warehouse, dbt for the modelling, Postgres behind the applications. If your firm already runs one of these, we work in it rather than quoting a migration you did not ask for.

Analytic warehouse

Snowflake

Our default for the modelled layer. Separated compute means a heavy month-end reporting run cannot slow a query on the desk.

Lakehouse & ML workloads

Databricks

Where the estate is already on Databricks, or the work is heavier than SQL: tick data, notebook research, model training on Unity Catalog governance.

Transformation

dbt

Version-controlled SQL modelling with tests, generated documentation, and lineage. Every change is reviewable and revertible in Git.

Ingestion

Fivetran & Airbyte

Managed connectors for the feeds that have them, Python on Airflow for the fund administrator report that still arrives as a file.

Reporting & BI

Power BI & Tableau

Whichever your firm already licenses, driven from a semantic model over the marts rather than each report writing its own SQL.

Application data

Postgres

Transactional store behind portals and internal tools, on Azure Database for PostgreSQL, kept distinct from the analytic estate.

Also in the toolchain

dbt CloudApache AirflowAzure Data FactoryUnity CatalogSnowflake CortexAnthropic ClaudeAmazon BedrockPythonNext.jsTypeScriptAzure DevOpsGitHub Actions
Managed workflows

The processes you run every week, built once and operated.

Joiners, movers, and leavers, access requests, recertification and vendor onboarding. RFA builds the workflow against your real runbook, then runs it. Tickets get raised, emails go on schedule, and approvals stop the process where a person has to decide.

  • Your runbook, not a template

    Built from the process you already follow, including the steps that only apply to one region or one desk.

  • Approvals as first-class steps

    Licensed and privileged access waits on your named approver. Nothing is provisioned ahead of the decision, and the trail is kept.

  • Run by the service desk

    The same engineers who answer your tickets operate the workflow, so an exception is handled rather than queued.

Map one of your processes

What this workflow does

7 steps

  1. An intake form is submitted

    Trigger

    Starts automatically when the hiring manager submits the new-starter form.

    Source Intake form · client portal

  2. 1

    Raise the joiner ticket

    Ticket

    Creates the master ticket the service desk works from: accounts, standard groups, hardware, and day-one readiness.

  3. 2

    Send the pre-start engagement email

    Automated emailEmail

    Goes to the joiner's personal address before day one, from your template.

  4. 3

    Raise the telephony and device tickets

    Ticket

    Calling setup and any corporate hardware order, raised early so the desk has lead time.

  5. Market-data access approval

    Your approvalApproval

    Licensed platforms wait on a named approver. The request goes to the approval group and any one of them can release it.

    Approver Per your approval matrix

  6. 5

    Provision the approved access

    Ticket

    Raised only once the approval succeeds, so a licence is never bought ahead of a decision.

    Waits for The approval above to complete

  7. 6

    Send day-one quick tips

    +9 hours after start dateScheduled

    Timed to land after the start date, so it arrives when it is useful rather than in the pre-start pile.

Example workflow, generalized. Real builds carry client-specific systems, approvers, and timings.

How we work

Scoped, documented, then operated.

01

Fixed scope, priced first

Discovery produces a written scope with deliverables, owners, and dates, priced before any work starts. Not open-ended staff augmentation billed by the month.

02

Documented at handover

Tests, generated docs, lineage, and a named owner per model or service. If your own engineers take it over later, they get something they can read.

03

Then run, not abandoned

What we build, we operate — monitored, patched, and supported on the same service desk and SLA as the rest of your estate.

What you get

The outcomes that matter to the business.

01

One governed data layer instead of a dozen vendor exports

02

Reporting that closes on time without manual assembly

03

Automation built on data the firm can defend

04

Engineering capacity without new headcount

Let's talk about your
technology needs.

Speak with an RFA advisor about IT, cybersecurity,
AI, and compliance for financial services.