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.
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
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 AirflowTransformation 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.
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
intermediate
The joins and reshaping that carry business logic: position to instrument, trade to strategy, investor to vehicle.
int_positions_enriched
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.
Four practices, and what each hands over.
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
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
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
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
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 ActionsThe 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.
What this workflow does
7 steps
An intake form is submitted
TriggerStarts automatically when the hiring manager submits the new-starter form.
Source Intake form · client portal
- 1
Raise the joiner ticket
TicketCreates the master ticket the service desk works from: accounts, standard groups, hardware, and day-one readiness.
- 2
Send the pre-start engagement email
Automated emailEmailGoes to the joiner's personal address before day one, from your template.
- 3
Raise the telephony and device tickets
TicketCalling setup and any corporate hardware order, raised early so the desk has lead time.
Market-data access approval
Your approvalApprovalLicensed 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
- 5
Provision the approved access
TicketRaised only once the approval succeeds, so a licence is never bought ahead of a decision.
Waits for The approval above to complete
- 6
Send day-one quick tips
+9 hours after start dateScheduledTimed 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.
Scoped, documented, then operated.
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.
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.
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.
The outcomes that matter to the business.
One governed data layer instead of a dozen vendor exports
Reporting that closes on time without manual assembly
Automation built on data the firm can defend
Engineering capacity without new headcount
Related services
All services →Managed AI
NewHours back for your team, on AI you can govern, secure, and evidence.
Learn more →Managed Cybersecurity
Threats found and contained around the clock, by analysts who work for RFA.
Learn more →Managed IT Services
One team accountable for the network, the servers, and the desk — so your people stop losing days to IT.
Learn more →Let's talk about your
technology needs.
Speak with an RFA advisor about IT, cybersecurity,
AI, and compliance for financial services.