Open to Technical BA / Systems Analyst roles · San Diego or remote · available now

Technical Business Analyst

I sit between the people who need a number and the engineers who build it — writing requirements precise enough to implement, in a stack I can build in myself.

Four-plus years across financial services, agency, and product analytics, on both sides of the handoff. I have gathered requirements from stakeholders who described a dashboard when they meant a decision, and I have been the engineer holding a spec that left the hard questions unanswered. That is why my specs answer them.

Email me Download résumé See the engineering work →

4+
years in analysis roles across credit, agency, and product: 8+
source systems mapped and consolidated into one analytics layer: 60%
lift in self-service analytics adoption after I documented definitions and trained staff: 98%
data accuracy after I turned business rules into automated validation

My analysis career started in credit and lending: three years building risk and anomaly models over financial and credit data, where a wrong number is an audit finding, not an awkward meeting.

Role fit

What the job asks for, and where I have done it

No adjectives. Each row names the work, the number, and the role it happened in.

Requirements gathering & stakeholder translation

Partnered with cross-functional stakeholders to translate business requirements into analytics solutions and reusable reporting across 8+ client accounts.

Business Analyst, Kallos Design & Marketing
Technical documentation engineers can build from

Documented data lineage, business definitions, and KPI logic for a credit and lending business — the artifact other analysts and engineers worked from.

BI & Data Engineer / Risk Analyst, Ferrum Capital
Systems integration & dependency mapping

Mapped and consolidated 8+ source systems into a single Snowflake analytics layer, identifying every dependency and gap before the first pipeline shipped.

Data & Growth Analyst, Rabalon
Data models & relational databases

Designed the dbt and Snowflake models standardizing KPIs for Product and Growth (500K+ records/day), and the BigQuery models behind executive reporting.

Rabalon · Ferrum Capital
Acceptance criteria & test outlines

Turned business rules into automated data-quality and validation checks inside the ELT — accuracy from ~88% to 98%, monthly-report rework down 30%.

Data & Growth Analyst, Rabalon
Architecture input & scalability trade-offs

Chose the consolidation architecture (land raw, model in dbt) and optimized BigQuery warehouse workloads ~45% faster for the reporting layer behind it.

Rabalon · Ferrum Capital
Subject-matter expertise & enablement

Became the reference for what each number meant, then trained staff to self-serve — self-service adoption up ~60% within six months.

BI & Data Engineer / Risk Analyst, Ferrum Capital
Technical fluency (build, not just specify)

Python, SQL, dbt, Snowflake, BigQuery, Power BI in production. I validate feasibility by prototyping it, which shortens the argument considerably.

Across all three roles

The artifact

A spec, start to finish

Most analyst résumés claim requirements skill. This is what mine actually produces: seven steps from an ambiguous request to acceptance criteria an engineer can build and a tester can verify.

Work sample

Credit-risk early-warning: from business ask to engineering spec

Reconstructed from a real build at a credit and lending business (2020–2023), with employer-specific table and field names generalized. The shape, the questions, and the acceptance criteria are the ones I actually use.

Step 1 of 7

What the stakeholder said

Verbatim, before any analysis. Written down because the wording matters later.

“We keep finding out about problem accounts too late. Can we get a report that shows us which ones are going bad?”

Three undefined terms in one sentence: “problem”, “too late”, and “going bad”.
A report was requested. A decision was described. Those are not the same deliverable.
No owner named yet, and no stated action to take when an account is flagged.

Step 2 of 7

The questions that had to be answered first

Requirements gathering is mostly refusing to guess. Each answer removed a build path.

I took these to the risk lead and the collections team separately, because they defined “problem” differently and both of them were right for their own workflow.

What decision changes when an account is flagged, and who makes it?
How much earlier than today is worth having? A day? A month?
What does a missed flag cost, versus a false alarm? (This sets the threshold, not statistics.)
Which existing definition of a delinquent account do we adopt, and who owns it?
How many alerts per week can the team actually work through?

Step 3 of 7

The requirement, stated so it can be built and tested

One user story, with acceptance criteria that a person other than me can verify.

As a risk analyst, I need accounts showing early deterioration signals surfaced weekly, so that outreach begins before an account reaches formal delinquency.

GIVEN an account with a deterioration signal in the scoring window, WHEN the weekly run completes, THEN it appears on the review queue with the contributing factors listed.
AND the queue is capped at the volume the team agreed it can work (alerts are worthless if they are ignored).
AND every flagged account records why it was flagged, retained for audit.
AND accounts already in formal delinquency are excluded — that is a different workflow.

Step 4 of 7

Data flow and interface points

Where the data comes from, what each hop guarantees, and who owns the edge.

The integration risk was never the model. It was the four upstream systems, each owned by a different team, each with its own idea of when a day ends.

Sources: core account ledger, payment history, customer master, external credit reference data.
Landing: raw, unmodified, timestamped on arrival. No cleanup at extraction (you cannot reconstruct what you dropped).
Modeling: point-in-time account state. Financial data must be reproducible as of a date, or the audit fails.
Serving: scored review queue plus the factor detail behind each score.
Named owner per source, and an agreed contact for schema changes. This was the part that actually prevented incidents.

Step 5 of 7

Business definitions, written down once

The single highest-value page in any spec I have written. Ambiguity here becomes a production defect later.

Two teams had been using “active account” to mean different things for years, and both had built reports on it. Nobody had noticed because the reports never sat side by side.

Every term used in the requirement gets one definition, one owner, and one location.
Definitions live next to the model that implements them, so they cannot drift apart silently.
“As of” semantics stated explicitly for every metric: event date, effective date, or reporting date.
Where a definition is contested, the spec records both readings and who decided between them.

Step 6 of 7

Test cases and edge cases, handed over with the spec

Written before implementation, so “done” is not a matter of opinion.

Each of these became an automated check rather than a manual review step, which is the only version of quality control that survives a busy quarter.

Account with no payment history: must not error, must not score.
Account whose upstream record arrives late: must be scored on the next run, not silently skipped.
Duplicate account records across source systems: must resolve to one, deterministically.
Backdated correction upstream: must change the point-in-time result for that date, and be visible as a change.
Zero-alert week: must be distinguishable from a failed run. (This one is always missing and it always matters.)

Step 7 of 7

What shipped

The number the spec was accountable for.

Python anomaly-detection and risk models over financial and credit data, surfacing potential issues 3 to 4 weeks earlier than the previous process and reducing escalation risk.

Earlier detection mattered because it moved accounts into a workflow that still had options.
The definitions page outlived the model. It was still in use after the scoring logic had been rewritten.
Documented lineage and KPI logic let the team self-serve; adoption rose ~60% within six months.

Background

The analysis thread

Business degree, analytics master's, engineering practice. The through-line is the same in all three: find out what the number is supposed to mean, then make the system produce it.

Jun 2025 — Jan 2026
Data & Growth Analyst · Rabalon
- Designed Python + SQL ELT on Snowflake and dbt consolidating 8+ source systems — manual data-prep down ~45%.
- Built analytics-ready dbt models standardizing KPIs for Product and Growth, processing 500K+ records/day.
- Automated data-quality rules in the ELT: dashboard accuracy up from ~88% to 98%, monthly rework down 30%.
- Cut the weekly reporting cycle from ~2 days to ~4 hours with reusable Power BI semantic models and DAX.
Python · SQL · Snowflake · dbt · Power BI
Sep 2024 — Jun 2025
Business Analyst Intern · Kallos Design & Marketing
- Built and automated ETL integrating marketing and customer data into a central warehouse powering dashboards across 8+ accounts.
- Translated stakeholder requirements into analytics solutions and reusable reporting.
Python · SQL · ETL
2020 — 2023
BI & Data Engineer / Financial Risk Analyst · Ferrum Capital
- Built Python anomaly-detection and risk models over financial and credit data, flagging potential issues 3–4 weeks earlier.
- Optimized BigQuery warehouse workloads ~45% faster and built the data models behind executive BI reporting.
- Documented data lineage and KPI logic and trained staff to self-serve — analytics self-service up ~60% in six months.
Python · BigQuery · SQL · BI
2024

M.S., Business Analytics (STEM) · University of California, Irvine

Capstone (AbbVie-sponsored): Python + SQL ETL over 1M+ healthcare records into BigQuery data marts, with XGBoost predictive and anomaly-detection models for executive analytics.
2021

B.B.A., Business Administration & Management · ADA University

Baku, Azerbaijan.