01 · THE PROBLEM
SQL access can bypass the application
A database administrator or intruder can insert a fake transfer, change the recipient or replace the amount. If processing trusts that row, a database edit can become a debit.
A database row should not be enough to move money.
Secure Transfer adds an authenticated path from a payment instruction to its execution. It addresses one specific risk: an attacker can change the primary transaction database, but must not turn those changes into an unauthorized transfer.
02 · THE CONTROL
Keep independent evidence of the authorized content
A separate key service authenticates the exact operation with an HMAC tag and saves an independent receipt. Someone controlling only the primary database cannot issue that tag or rewrite the receipt.
03 · THE EXECUTION
Check the exact instruction before changing balances
The processor checks the receipt and MAC, reads the source again, and executes only the checked snapshot. Audit/Protected DB commits both sides of the transfer together and prevents a second debit on retry. Java performs the calculations; the database enforces atomic storage.
04 · THE RESULT AND ITS LIMIT
A changed row does not automatically authorize a payment
A fabricated instruction is quarantined without postings. This guarantee assumes that the application, key service, processor, Audit/Protected DB and local host remain trusted. It does not protect a compromised whole computer or hide database contents.
This document opens directly from disk, without a server or application. The live lab uses simulated money and dedicated accounts. A suspected integrity incident also queues a minimal email alert in protected storage. Local Mailpit captures that alert for inspection; it does not deliver to Gmail. Evidence below separates the latest failed throughput gate from historical successful runs and notification checks.
Three modules. Two databases. An embedded queue.
Rectangles are services. Cylinders are databases. Follow one numbered arrow at a time; the blue outline identifies the components involved.
Where each record lives
| Store | Important tables | What they mean |
|---|---|---|
| Primary DB | transactions, transaction_outbox, transaction_status_events | Candidate instructions, delivery hints and status projections. No authoritative balances. |
| Audit/Protected DB · evidence | issuance_receipts, audit_events, audit_checkpoints, notification_outbox | Original authenticated content, checks, outcomes, incidents, checkpoints and the first durable notification per operation. |
| Audit/Protected DB · accounting | accounts, operation_jobs, ledger_postings, operation_results, settlement_outbox | Authoritative balances, durable work, double-entry postings, execution deduplication and outcome delivery. |
MAC tag ≠ secret key. Verification does not issue a replacement tag. No trigger starts this flow: the application writes an outbox; the processor polls it and publishes persistent UUID hints to embedded ActiveMQ. Its consumer commits a protected SQL job before acknowledging delivery. A VERIFIED audit event alone never authorizes settlement.
Optional incident side channel: the incident event and initial notification commit together in Audit/Protected. A separate dispatcher retries delivery to configured recipients. SMTP failure does not authorize an invalid transfer or block financial execution. Mailpit's local inbox requires the running stack; notification configuration and limits are readable offline. SMTP acceptance is not inbox delivery; a crash can cause duplicate email. A discrepancy is not proof of fraud.
Production target and remaining infrastructure
Not deployed: independent IAM and operators, a real KMS/HSM adapter, encrypted service transport, independently retained checkpoints and tested backup/PITR recovery. The current demo places all services on one trusted Windows host.
A transfer, from request to durable result
Read top to bottom. Numbers match Architecture. ActiveMQ runs inside Module 3; both protected table groups share one database.
Normal path; responses are summarized. No receipt → quarantine, no postings. Incident → protected notification outbox → separate email dispatcher; SMTP is not a settlement gate. Reconciliation and Merkle checkpoints run separately. No cross-database/JMS global transaction.
Evidence, including the failed threshold
The latest throughput measurement is September 7, 2026, before incident email support. September 8 notification checks are separate functional evidence. Nothing on this page runs a test in your browser.
unique completed transfers · September 7
transaction failures, not failed gates
p95 completion latency · September 7
| Measurement | Recorded result |
|---|
Completion includes the protected outcome, correct postings and delivered audit evidence. This is a 120-second software-key simulation on one Windows host. Maximum capacity, a million-record history, a ten-minute soak and comparative cost were not measured.
Read the latest failed acceptance report. All 2,400 operations completed with correct protected accounting and durable audit, but 19.9636 TPS is below the strict 20 TPS threshold. It is not rounded into a pass.
Historical successful benchmark · September 6
Missing unpublished receipt detection took 32.96 seconds under a 120-second observation budget, not a production SLA. Read the preserved historical pass. Earlier September 5 and initial September 6 reports remain retained unchanged.
Incident notifications · September 8
The implementation revision passed 137 Java tests in 19 suites, 44 Node checks and 18 PostgreSQL role-isolation checks before this publication update. These counts do not claim a new throughput pass.
| Local capture case | Recorded result |
|---|
Read PostgreSQL-to-Mailpit evidence. No external Gmail delivery, production SMTP handshake, new load run or email availability guarantee was tested. Email reports a suspected incident; post-settlement source tampering does not undo the original protected execution.
Functional and attack checks · September 7
| Scenario from report | Result |
|---|
Historical Live Lab integration · September 6
The lab was checked separately for protected funding, a valid transfer, a direct-primary forgery, safe retries, fresh demonstration identities and rejected unauthorized web requests. This is functional API/database evidence, not another load run or a browser visual test.
Publishable JSON evidence
Terms in plain language
Start with HMAC, issuance receipt and settlement, then explore retries and audit history.
Study and presentation materials
Live transaction labReal local services, dedicated fixtures and a fixed direct-database forgery.
Updated article · PDFTechnical article with measured results and explicit limits.
LinkedIn publishing kitFormatted post, copy button and downloadable cover image.
Medium article copyFull text, employer disclaimer and public supporting references.
Publishing guideWhich text to copy and which file to attach.
Technical presentation · PowerPointEditable slides and speaker notes.
Presenter handbookRehearsal, terms, commands and audience questions.
Read the article in your browserFull technical glossaryArchitecture and acceptance criteriaIncident notifications: local capture and real SMTPDownload the complete documentation pack
The offline package explains the system. Actual local experiments additionally require the complete project, its running Java/PostgreSQL stack and the loopback lab helper. Never share the .local folder containing credentials and keys.