Technical Screening Overview

I design secure, high-throughput B2B platforms that reconcile fragmented data streams, enforce tenant isolation at the database layer, and map directly to HIPAA and SOC 2 control requirements.

My core asset is a multi-channel reconciliation pipeline: SWIFT registry data, M-Pesa B2B transactions, and SAP ERP records are ingested asynchronously, normalized, and written to PostgreSQL registers with row-level security (RLS) so each tenant can only see its own data. Automated discrepancy triggers and audit logging cut manual review by roughly 90%, while component-driven CI/CD pipelines compress delivery lifecycles by up to 80%.

I bridge engineering and governance — translating policy requirements into technical controls, risk registers, and audit-ready evidence rather than treating compliance as a checkbox.

Context: Enterprise finance and health platforms lose capital and velocity when data sits in disconnected systems. Manual reconciliation is slow, error-prone, and expensive to audit.

What I built: A multi-tenant B2B reconciliation and settlement engine that ingests data from SWIFT, M-Pesa B2B, and SAP ERP, normalizes it into a canonical schema, and stores it in PostgreSQL with strict tenant boundaries enforced by Row-Level Security.

How it works:

• Async ingestion: Each source posts or streams events independently. The pipeline queues work, decouples producers from consumers, and retries transient failures without blocking the critical path.
• Normalization layer: Heterogeneous formats are mapped to a shared ledger schema with transaction references, expected/actual amounts, currencies, and origin sources.
• Discrepancy detection: Database triggers and comparison jobs flag structural breaks automatically, surfacing exceptions for human review only when the machine cannot resolve them.
• Tenant isolation: RLS policies bind every row to a tenant_id and every query to the authenticated user, so isolation is enforced at the data layer — not just the UI.
• Audit and compliance: Timestamps, change triggers, and immutable logs feed risk registers and control evidence mapped to HIPAA Security Rule safeguards and SOC 2 Trust Services Criteria.

Outcome: ~90% less manual audit review, up to 80% faster prototype-to-production cycles, and a system architecture that can be presented to enterprise buyers and auditors.

Problem: Financial and healthcare platforms reconcile transactions across SWIFT wire registries, mobile B2B networks like M-Pesa, and ERP systems such as SAP. Each source uses different formats, identifiers, and timing, so manual matching is slow and error-prone.

Design:

• Reference registry: A lookup table stores expected transaction references, amounts, currencies, and origin sources. This becomes the source of truth against which incoming records are matched.
• Reconciled ledger: Actual transactions land in a separate ledger with statuses such as matched, pending, exception, or resolved.
• Matching engine: A deterministic matcher compares transaction_reference, amount, and currency; fuzzy rules handle minor formatting differences and currency rounding.
• Exception workflow: Unmatched items are surfaced with context so analysts investigate the exception, not every row.

Key metric: Automated discrepancy detection reduced manual audit review overhead by an estimated 90%.

Talking point: “I treat reconciliation as a control, not just a reporting task. Every exception is logged, every match is auditable, and the ledger itself is protected by tenant-scoped RLS.”

Why RLS: In multi-tenant systems, tenant isolation is often enforced in application code. That is fragile — one missed WHERE clause can leak data. I push isolation down to PostgreSQL Row-Level Security so the database itself rejects cross-tenant reads and writes.

Implementation pattern:

• Every tenant-scoped table carries a tenant_id column.
• RLS policies compare tenant_id against the authenticated application user, set via a secure configuration parameter or Supabase auth.uid().
• Even service-role operations are scoped by default; privileged admin queries are explicit and logged.
• Policies are combined with least-privilege grants: anon gets no access, authenticated users get only the operations their role requires, and service_role is reserved for backend automation.

Compliance tie-in: This pattern mirrors HIPAA technical safeguards for access control and minimum necessary access, and it supports SOC 2 logical access controls. It also makes penetration testing and audit evidence easier because the control lives in the schema.

Talking point: “I do not trust the application to remember the tenant filter. The database enforces it on every query, so a bug in one endpoint cannot escalate into a breach.”

Approach: I translate regulatory requirements into concrete system controls, then document them in a control matrix that auditors and enterprise buyers can read.

Talking point: “I do not hand auditors a spreadsheet of promises. I hand them the SQL policies, trigger definitions, and log samples that prove the control is operating.”

Why async: SWIFT, M-Pesa, and SAP do not produce data on the same schedule or format. Synchronous ingestion would couple availability and create retry storms. Asynchronous queues decouple sources from processing and let each side move at its own speed.

Flow:

• Ingest: Source systems push files, webhooks, or API events into a durable queue or staging table.
• Normalize: Workers read from the queue, validate schema, convert currencies, and map records to the canonical ledger format.
• Match: The matcher compares actuals against the reference registry and marks records matched, pending, or exception.
• Resolve: Exceptions route to a human review queue with full context; resolved items update the ledger and emit audit events.
• Report: Dashboards and API endpoints read the reconciled ledger under RLS, so each tenant sees only its own settlement status.

Resilience patterns: Idempotent workers, dead-letter queues for poison messages, exponential backoff retries, and at-least-once delivery with deduplication keys.

Talking point: “The pipeline is designed for partial failure. If SAP is slow, SWIFT and M-Pesa records still flow, match, and settle. Nothing blocks the critical path.”