Closing the Accountability Gap Between Financial Advice and Financial Action

Designing reviewable, reversible, and auditable decision workflows

Abstract

Financial software often treats advice and action as separate product categories. Planning tools explain what a person might do. Transaction systems execute instructions. The difficult engineering problem sits between them: turning a recommendation into a decision that a person can understand, change, authorize, revoke, and inspect later.

I call this the accountability gap.

Closing it requires more than a good recommendation algorithm. It requires a workflow in which inputs have explicit confidence, recommendations carry reasons, changes create new versions, approval is distinct from calculation, execution is constrained by authorization, and every important transition leaves evidence.

This paper describes that architecture through lessons from building a monthly cash-flow planning system. The current implementation stops short of live money movement; its transfer ledger is simulated. That limitation is useful because it forces the design question into the open: what would have to be true before a recommendation could safely become an external action?

1. The missing middle

A recommendation is easy to represent as a number:

Put $500 toward the emergency fund this month.

But that number hides the decisions that make it defensible:

• Which accounts and transactions were included?
• How much cash was protected from routing?
• Which recurring obligations were projected?
• What goal ordering was applied?
• Was the input data complete enough to support a recommendation?
• Did the user change the amount?
• Which version did the user approve?
• Can that approval be revoked?
• What would prevent an old approval from authorizing a new plan?
• What evidence remains when support investigates the outcome?

If the system cannot answer those questions, the recommendation is not ready to cross an action boundary. A polished explanation in the interface does not repair an unaccountable state model underneath it.

The mistake I wanted to avoid was treating approval as a boolean attached to a mutable recommendation. That design looks efficient until the recommendation changes. Then approved = true no longer tells us what was approved.

The safer model treats a recommendation as the beginning of a workflow, not its final output.

2. The accountability pipeline

The architecture can be summarized as seven stages:

Accountability pipeline: Observed facts → conservative derived state → explained proposal → versioned plan → human decision → authorization boundary → outcome ledger → audit and review evidence.

Each boundary answers a different question:

1. Observed facts: What did the system receive?
2. Derived state: What did it calculate, and with what confidence?
3. Explained proposal: What does it recommend and why?
4. Versioned plan: What exact artifact is under review?
5. Human decision: Was it adjusted, approved, skipped, or revoked?
6. Authorization boundary: Is this version currently permitted to proceed?
7. Outcome evidence: What was scheduled, attempted, completed, canceled, or blocked?

Combining these stages saves tables and endpoints, but it destroys meaning. A projection is not a recommendation. A recommendation is not an approval. An approval is not execution. An execution attempt is not an outcome.

3. Start with conservative derived state

Accountability begins before the recommendation exists.

In the cash-flow system behind this case study, the monthly calculation uses observed account and transaction data, recurring income and obligation signals, profile baselines, and protected-balance settings. Its safe-to-route amount is bounded twice:

projected month-end surplus = projected income - projected spend

available cash = total cash - protected cash

safe to route = max(min(projected month-end surplus, available cash), 0)

The formula matters less than its posture:

• negative surplus produces zero;
• projected surplus cannot exceed available cash;
• protected balances reduce what can be proposed;
• sparse transaction history falls back to the more conservative spending baseline;
• internal transfers are excluded from income and spending;
• low-confidence calculation suppresses the recommendation instead of guessing.

That last rule is the most important. A system that cannot calculate confidently should return no recommendation and explain why. Availability pressure often pushes teams toward best-effort output, but a blank proposal is safer than a confident-looking number built from invalid inputs.

Failing closed does create product work. The user needs a recovery path: reconnect an institution, classify transactions, confirm income, or correct an account setting. That is not a reason to weaken the confidence gate. It is evidence that recovery is part of the product.

4. Make the recommendation explain itself

An accountable proposal is structured data, not only display copy.

For each routing item, the system records fields such as:

• priority step;
• rule name;
• destination account;
• proposed amount;
• reason;
• related goal;
• warnings or readiness notes.

A deterministic rule engine makes those explanations reproducible. An emergency fund recommendation can state its target and current balance. A debt recommendation can identify the rate threshold it crossed. A goal allocation can identify the goal priority and remaining need.

This is not the same as asking a language model to explain a number after the fact. Post-hoc prose can sound plausible without reflecting the calculation. The reason should be emitted by the decision path that produced the recommendation.

Generative systems can still help summarize or translate that evidence. They should not invent it.

5. Version the artifact under review

Once a person can change a recommendation, the system needs immutable identity for the reviewed artifact.

The model I settled on creates a new monthly-plan version when material routing content changes. The active plan points back to its parent, while prior versions remain available for history. Adjustments record the actor, reason, and affected plan.

This changes the approval question from:

Did the user approve a plan?

to:

Did the user approve version 3 of the August plan, derived from proposal X, containing these final routing items?

That precision prevents several common failures:

• an approved plan being silently edited in place;
• support seeing only the latest values without the path that produced them;
• an old approval being applied to a new recommendation;
• a user being unable to distinguish the proposed amount from the final amount.

Versioning also makes disagreement manageable. An advisor can prepare one version, a client can adjust it, and both can see the delta without overwriting each other’s contribution.

6. Separate approval from execution

Approval is a grant of authority over a specific artifact. It is not evidence that an external action occurred.

In the case-study implementation, approval and execution use separate records. The approval captures recommended, adjusted, and final routing values, the actor, the period, and the review timestamps. A later execution workflow references both the plan and the approval and verifies that their subject, organization, and assignment context agree.

Sensitive transitions require renewed proof through step-up verification. A successful session is not treated as permanent authority for every consequential action.

The resulting state model supports explicit outcomes:

• pending: available for review;
• adjusted: changed but not silently substituted;
• approved: authorized for the defined boundary;
• skipped: intentionally not acting this period;
• revoked: future action is blocked;
• scheduled or completed: outcome states in the ledger, not synonyms for approval.

Revocation deserves first-class status. If a system offers approval but handles revocation as an exceptional support operation, authority is not really in the user’s hands.

7. Preserve subject, actor, and authority

Advisor-managed workflows introduce a second accountability problem: the person preparing a plan may not be the person authorizing it.

Every consequential record therefore needs enough context to answer:

• Who is the subject of the plan?
• Who created or changed it?
• Under which organization?
• Through which advisor-client assignment?
• Which role was the actor exercising?
• Which approval authorized the next transition?

Those dimensions should not be inferred later from whichever membership happens to be active. Memberships and assignments change. Historical evidence should retain the context that was true when the action occurred.

This is one reason I do not treat audit logging as a generic stream of messages. The audit model is part of the domain. Actor, subject, organization, relationship, target, action, request identifier, and changed fields are business data.

8. Design the ledger before connecting a rail

The current system uses a simulated transfer ledger. The independently built fintech application, Badgerlane, does not move money.

That boundary is not a footnote. It separates what the software proves today from what a production money-movement integration would still need to prove:

• provider authorization and account eligibility;
• idempotent submission;
• durable provider identifiers;
• pending, settled, failed, returned, and canceled states;
• cutoff times and scheduling semantics;
• reconciliation against provider truth;
• fraud, KYC, AML, and operational review appropriate to the expanded scope;
• user notification and dispute handling;
• recovery when local state and provider state diverge.

The simulated ledger is still useful. It validates the plan-to-approval-to-ledger shape without pretending the final rail exists. It exposes whether the state model can distinguish intent from outcome before external side effects make mistakes expensive.

9. Test denials and transitions, not only calculations

A decision workflow is not proven by unit tests for the formula alone.

The case-study test set covers:

• low-confidence routing suppression;
• protected-balance limits;
• plan adjustment creating a new version;
• approval requiring step-up verification;
• skip and revocation transitions;
• plan and approval identity checks;
• execution blocked after revocation;
• user and session isolation;
• cross-tenant and unassigned-client denials.

The negative cases carry much of the safety argument. It is useful to know that an approved plan can proceed. It is more important to know that an outdated, cross-tenant, revoked, or mismatched plan cannot.

I have found that state diagrams become far more honest when every arrow must earn a test and every missing arrow becomes an expected denial.

10. Practical design rules

The work produced a set of rules I would reuse in any consequential recommendation system:

1. Treat input confidence as part of the result.
2. Suppress low-confidence recommendations instead of filling gaps with optimism.
3. Emit reasons from the calculation path.
4. Version any artifact a person can approve.
5. Bind approval to a specific version and context.
6. Keep recommendation, authorization, attempt, and outcome as separate concepts.
7. Make skip and revocation normal states.
8. Carry actor, subject, tenant, and relationship context into history.
9. Test forbidden transitions and mismatched context explicitly.
10. State the limits of the current execution boundary in plain language.

Conclusion

The gap between advice and action is not closed by adding an approval button.

It is closed when the system can show where a recommendation came from, what changed, who authorized which version, what authority remains, what happened next, and how the result can be investigated without reconstructing the truth from logs.

That is an architectural property. It comes from conservative calculations, explained proposals, versioned state, explicit authority, reversible transitions, and durable evidence.

The broader lesson is not limited to finance. Any system that turns generated or calculated guidance into consequential action—security remediation, infrastructure changes, clinical workflow, compliance review, or AI-agent execution—has the same accountability gap.

The recommendation is only the beginning.