TrustVault

Overview

TrustVault was my entry to the Nomba hackathon, where the challenge was to build a secure API over Nomba's payments platform. Most payment tooling helps businesses move money. TrustVault helps them move it safely. It sits between a business and Nomba, keeps its own record of customers, virtual accounts, transactions and webhooks, and inspects every outgoing transfer before it happens.

It is almost entirely backend work: the API, the integration, the scoring engine and the audit trail.

The problem

Receiving money is the easy half. A customer pays into an account, the provider sends a webhook, the business records it. Sending money is where fraud, human error and suddenly-risky customers live: a transfer to the wrong account, a compromised user, a velocity spike. Blocking everything is useless; allowing everything is dangerous. Operators need something in between.

The solution

• Dedicated virtual accounts are created through Nomba and mirrored locally, with suspend, close and archive lifecycles.
• Incoming webhooks are verified against a signature computed over the raw request body, then reconciled into transactions and audit entries.
• The Trust Engine scores each customer from 0 to 100 using signals TrustVault already holds.
• Transfer Guard runs before every outgoing transfer and returns ALLOW, REVIEW or BLOCK. Only ALLOW reaches Nomba.
• Every important action writes an audit log.

Architecture

1. Clients

   • Operator dashboard
   • API clients
   • Nomba webhooks
2. Controllers

   • Users
   • Virtual accounts
   • Transfers
   • Webhooks
   • Trust engine
   • Dashboard
3. Services

   • Transfer Guard
   • Trust Engine
   • Webhook verification
   • Audit logging
4. Integrations & data

   • NombaService
   • PrismaService
   • PostgreSQL

Engineering challenges

A score you can read

The Trust Engine deliberately isn't machine learning yet. It starts every customer at 50 and applies clear, inspectable rules (account status, account age, trusted and revoked devices, successful and failed payments, virtual-account history, the severity of audit events and recent activity), then clamps the result between 0 and 100. Every score comes back with the signals that produced it, so an operator can see why a transfer was held.

Deciding before the money moves

Transfer Guard validates the amount, loads the customer and optional virtual account, asks the Trust Engine for a score, looks up the recipient through Nomba, checks amount, velocity, recipient and risk history, and only then decides. A transfer that needs a human is stopped with its reason recorded, not silently dropped.

Webhooks you can trust

A webhook is an unauthenticated stranger until proven otherwise. Signatures are computed with HMAC over the raw body (parsing first breaks the signature) and compared in constant time, verified events are persisted, and matching events create transactions and audit records. Tests cover missing signatures, bad signatures and the full ingestion path.

Outcome

A working payment-security service delivered inside a hackathon window: virtual accounts, verified webhooks, an explainable trust score, a transfer gate and a full audit trail, all covered by unit and controller tests. The dashboard was embedded in the backend to avoid a second deployment, a pragmatic call under time pressure.

Lessons learned

• Explainable beats clever when money is on the line. Rules first; models once there's data to train them.
• Raw bodies matter. Signature verification is only as good as the bytes you verify.
• Thin controllers age well. Keeping provider logic out of controllers made Transfer Guard testable on its own.