Liquidity risk management software goes live safely when three things are true: it reads the bank's own feeds every morning and ties them to the general ledger, it applies the bank's own early warning indicators and limits rather than a vendor's defaults, and it has run in parallel with the existing process long enough for the second line to sign that the two agree or that every difference is explained. For a bank whose data can be reached, that is weeks of work, not quarters, and most of it is the bank's own people deciding what the policy already says. Botminds' Liquidity Risk Monitoring is an agentic solution for treasury and second-line risk teams: seven agents recompute the indicators and the survival horizon, trace each move to the depositors behind it and draft the next step, while the analyst confirms, the treasurer decides and the liquidity risk officer checks. This guide lays out a six-week plan to put it live, every duration a target, with the checks each week must pass.
The plan is Botminds' design for a bank of moderate complexity with access to its feeds; it is a target, not a measured implementation. Screens come from the solution's fictional sample bank, Corvane National Bank. Rules are the agencies', linked where they appear.
Liquidity Risk Monitoring live in six weeks: who works in which week
- Policy and indicators inW1
- Cohorts mappedW2
- History reconciledW3
- Stress week replayedW4
- Parallel morningsW5–6
- Limits and approversW1
- WaitsW2
- Challenges differencesW3
- Reviews replayW4
- ChecksW5
- SignsW6
- Access and rolesW1
- Six feeds and tie-outW2
- Late-file drillW3
- Not involvedW1–4
- Tests evidenceW5
- OpinionW6
How long does it take to implement liquidity risk management software?
Our plan targets six weeks from the first meeting to the first morning the bank relies on the solution, of which two are a parallel run. The length is set less by the software than by three things on the bank's side: whether account-level data can be reached, whether the indicators and limits are written down, and whether the collateral position can be produced daily.
Each of those is a known delay. The FDIC's manual notes that "For some institutions, gathering and measuring information on specific accounts may not be feasible due to information system limitations" (FDIC RMS Manual, Section 6.1); a bank in that position starts with what its core can export and adds the payments hub later. A policy that names indicators but not their warning levels or limits needs the second line and ALCO before week one can finish. And the collateral file is often the slowest: the 2010 policy statement expects a bank to be able to calculate all its collateral positions promptly, but many collateral systems still produce a file once a day, in the evening.
What data does liquidity risk management software need?
Liquidity risk management software needs account-level deposit balances, payment flows, the general ledger, sweep activity, the ALM model's stress cash flows, collateral and borrowing capacity, and the bank's written policy: its indicators, limits, contingency funding plan and roles. The feeds are read-only; nothing in the solution writes back to a bank system.
What Liquidity Risk Monitoring reads, from where, and the test each feed must pass before go-live
| Input | Source | Why it is needed | Go-live test |
|---|---|---|---|
| Deposit balances by account, with sector and insured status | Core banking system | Every deposit indicator, the uninsured share, cohorts and the largest depositors | Total ties to the general ledger within the bank's tolerance on 20 business days |
| Fedwire, ACH and book transfers | Payments hub | Tracing a move to the clients and channels behind it; intraday watch | A known large outflow from last quarter is traced to the right accounts |
| Deposit tie-out | General ledger | Proving a drop is real and not a booking difference | A deliberate break is caught and the morning note refuses a clean number |
| Sweeps and sweep instructions, with change times | Treasury management system | Seeing a client's decision to move cash, sometimes before the money leaves | Instruction changes appear with their time and the user who changed them |
| Stress cash flows by scenario | ALM model output | The survival horizon and every what-if | The horizon matches the ALM team's own figure for the same run |
| Pledged collateral and lendable value | Collateral management system | Discount window and FHLB capacity in the horizon | A late file marks capacity Stale everywhere it is used |
| Indicators, warning levels, limits, plan stages and roles | Liquidity risk policy and contingency funding plan | What counts as a trip, who decides and who checks | Every limit has an approver on record; the stage 1 notice drafts from the plan's own text |
Six weeks, week by week
The weeks are ordered so that nothing is relied on before it has been tested on the bank's own data, and so that the second line sees every difference before it signs. Each week ends with a check that has to pass before the next begins.
Week 1, policy and access. Treasury loads the liquidity risk policy, the contingency funding plan and the indicator list, with each warning level and limit; the liquidity risk officer confirms who proposes, approves and ratifies a change. IT grants read access and sets the roles, including which roles may see client names. The check: every indicator has a definition, a source, a warning level, a limit and an approver.
Week 2, feeds and tie-out. The six feeds connect, and the Feed Steward agent starts checking arrival, completeness and the core-to-general-ledger tie-out every morning. Treasury maps the cohorts that can move together: uninsured commercial deposits by sector, public funds, brokered and listing-service money, the largest depositors. The check: five clean mornings, and one deliberate break caught.
Week 3, history. The indicators are recomputed for the last 20 business days and compared, line by line, with the bank's own spreadsheet. Every difference gets a cause: a definition the spreadsheet applied differently, a late file, a formula error on either side. IT holds back a file to prove the stale marking works. The check: no unexplained difference above tolerance.
Week 4, a stress week. Treasury picks the week of its largest recent outflow and replays it: which indicators would have fired, when, and whether the agents named the same depositors the team found by hand at the time. Replaying early warning indicators describes the method. The check: the second line accepts the replay as evidence.
Weeks 5 and 6, parallel mornings. The note arrives at 7:30 a.m. alongside the existing process. The analyst confirms facts in both; the treasurer decides on both; every difference is logged. The liquidity risk officer exercises a limit change through maker-checker, and internal audit tests the evidence trail. The check: the second line signs, and ALCO is told the date the old process stops.
Does liquidity risk management software replace the ALM model?
No. In Liquidity Risk Monitoring the ALM model stays the source of stress cash flows and the home of the bank's assumptions; the Monitor agent reads its output each morning and re-runs the survival horizon and what-ifs on it, and never changes an assumption or the model. The split matters because assumptions are a governance object. The policy statement says institutions "should ensure that the assumptions used are reasonable, appropriate, and adequately documented" and "should periodically review and formally approve these assumptions" (Interagency Policy Statement).
It is also where examiners are looking. The Federal Reserve reported that "Liquidity risk-management examinations in the second half of 2025 focused on reviewing firm internal liquidity stress testing deposit assumptions" (Federal Reserve, Supervision and Regulation Report, June 2026). Software that quietly re-estimates run-off rates would put a second, unapproved set of assumptions next to the approved one. What the solution adds is the daily evidence about which depositors are behaving differently from the assumption, for the people who own it to weigh. The ALM model itself remains a model under the 2026 interagency model risk guidance, SR 26-2; how SR 26-2 treats a risk model sets out what that guidance covers.
Can liquidity software run alongside spreadsheets?
It should, for the parallel run, and many banks keep a spreadsheet afterwards as a fallback. The policy statement accepts that "Cash flow projections can range from simple spreadsheets to very detailed reports depending upon the complexity and sophistication of the institution and its liquidity risk profile under alternative scenarios." What a spreadsheet cannot do easily is the morning's chain of evidence: a citation behind each number, a stale mark on each late input, an approval on each limit change and a recorded reason for each decision.
The same parallel morning in the spreadsheet and in Liquidity Risk Monitoring
Spreadsheet process: Files pasted in by hand; a late file leaves yesterday's numbers in place unless someone notices.
Liquidity Risk Monitoring: Files checked on arrival and tied to the general ledger; anything from a late file is marked Stale.
Spreadsheet process: Formulas maintained by one person; changes visible only by comparing versions.
Liquidity Risk Monitoring: Definitions and limits under maker-checker; the register shows when each was last approved.
Spreadsheet process: A payments trace by hand when an indicator trips.
Liquidity Risk Monitoring: Cohort, clients and channels traced and cited before the analyst arrives.
Spreadsheet process: An email, or a conversation.
Liquidity Risk Monitoring: A reason code and a reason, recorded and not editable.
Spreadsheet process: Assembled from email and files when asked.
Liquidity Risk Monitoring: An export with readings, decisions, limit changes and approvals, masked and hashed.
Who signs off before liquidity software goes live?
The liquidity risk officer signs that the numbers are right and the controls work, internal audit gives its view on the evidence, the treasurer accepts the morning process, and ALCO is told the date the old process stops. The policy statement expects internal controls of "procedures, approval processes, reconciliations, reviews, and other mechanisms designed to provide assurance that the institution manages liquidity risk consistent with board-approved policy," and an independent party to review the process regularly. For the largest holding companies, Regulation YY requires that review function to be independent of the managers who execute funding (12 CFR 252.34(d)).
Who is responsible, who approves and who is told, by week
| Week | Responsible | Approves | Told |
|---|---|---|---|
| 1 · Policy and access | Treasury; IT for access and roles | Liquidity risk officer: indicator list, limits and approvers | ALCO, that the parallel run starts |
| 2 · Feeds and tie-out | IT; treasury for cohort maps | Treasury: the tie-out tolerance | Liquidity risk officer |
| 3 · History | Treasury analyst | Liquidity risk officer: each explained difference | Internal audit |
| 4 · Stress week | Treasury analyst and treasurer | Liquidity risk officer: the replay as evidence | CFO |
| 5 · Parallel mornings | Analyst confirms; treasurer decides | Liquidity risk officer: limit change and escalation checks | Internal audit, which starts testing |
| 6 · Sign-off | Treasurer | Liquidity risk officer signs; internal audit gives its opinion | ALCO and the board's risk committee: the cut-over date |
Maker-checker on a limit change, exercised during the parallel run
How do you test liquidity software before relying on it?
You test it by trying to make it wrong in the ways a real morning goes wrong: a late file, a booking break, a limit someone wants to move, a cause that is plausible but untrue. The tests below are the checks in our plan; each takes less than a day and each leaves evidence the second line can keep.
Go-live tests for Liquidity Risk Monitoring, and what passing looks like
- Twenty mornings reconciled
Every indicator matches the bank's own calculation, or the difference has a written cause the liquidity risk officer accepts.
- A file held back
Every value that depends on it is marked Stale with the time of its last good value, and the indicators re-run when the file lands.
- A general ledger break planted
The tie-out fails, the note says so, and no indicator is published as clean.
- A real outflow traced
The agents name the same depositors the team found by hand, and every statement opens its source record.
- A weak cause offered
Below the confidence threshold, 0.70 in the sample bank, the cause appears as a question for a person, not as a fact.
- A limit change by its own proposer
The proposer cannot approve it; the liquidity risk officer can; ALCO ratifies.
- A decision edited the next day
The recorded decision cannot be changed; a correction is a new entry with its own reason.
- Client names requested
Only permitted roles can show them, each time with a logged reason; account numbers stay masked to the last four digits.
What does an examiner want to see at go-live?
An examiner will want to see that the new process is governed at least as well as the old one: approved definitions and limits, evidence that the numbers were reconciled before reliance, an independent review, and a record of decisions with reasons. Examiners rarely ask about software; they ask about control. Signature Bank's failure is the reminder of what they look for, because its examiners had flagged "recurring liquidity risk management concerns" and found that its practices "were not commensurate with the institution's complexity, risk profile, and scope of operations due to weaknesses with liquidity contingency planning, liquidity stress testing, and internal controls" (FDIC, April 2023).
The parallel run produces exactly that evidence if it is kept. In the sample bank, internal audit builds an export in one step: indicator readings with their sources, decisions with reasons and evidence, limit changes with approvals, stage 1 notices and their checks, and the agents' and models' versions, with client names masked and each file hashed.
The evidence an examiner asks for, built in one step in Liquidity Risk Monitoring
Where liquidity risk management software does not fit
A go-live plan is also the moment to be clear about what the software will not do. Liquidity Risk Monitoring does not produce the FR 2052a or a regulatory LCR; banks that file them keep their reporting process, covered in liquidity reporting in US banks. It does not replace the ALM model or the treasury management system. It does not write or test the contingency funding plan itself, which belongs to the bank's contingency funding plan work (what a plan you can test must contain); it drafts the stage 1 notice from the plan's text and holds it until the treasurer and the liquidity risk officer act. It never holds, stops or delays a payment.
It is also not the right first purchase for every bank. A bank with a granular, mostly insured deposit base, little payment activity and no history of fast outflows may find that a reliable monthly report meets its needs; the case for a daily, explained view grows with uninsured concentration, sector exposure and payment volume. The agencies' own posture on agentic tools is a further reason for a parallel run: the OCC reports that banks mostly use such tools in narrow cases, with guardrails and a person accountable for the outcome (OCC, Spring 2026). The questions to settle before choosing a tool are in liquidity monitoring tools: 15 questions, and the morning the bank goes live to is traced in a liquidity dashboard morning, step by step. The solution itself is on the Liquidity Risk Monitoring page.
Questions people ask
What are the steps to go live with liquidity risk software?
Load the policy, indicators and limits with their approvers; connect and tie out the feeds; reconcile the indicators on recent history; replay a real stress week; then run in parallel with the existing process until the second line signs. Botminds' plan for Liquidity Risk Monitoring targets six weeks for those steps, of which two are the parallel run.
How much history does liquidity software need before go-live?
Enough to reconcile and to replay: our plan uses the last 20 business days for reconciliation and the bank's largest recent outflow week for the replay. Botminds offers to run the solution on a bank's own early warning indicators and a month of its balances and payments, so the replay starts from the bank's data.
Does generative or agentic AI fall under model risk guidance?
Not under the current interagency guidance. SR 26-2, issued in April 2026 to replace SR 11-7, states that generative and agentic AI models are outside its scope, and the agencies have said they plan a request for information on AI. Banks still need governance for such tools; the OCC reports that most use them with guardrails and human-in-the-loop accountability.
Who owns the limits after the software goes live?
The same people as before. In Liquidity Risk Monitoring a limit or warning level changes only through a proposer, the liquidity risk officer's approval and ALCO's ratification, and the proposer cannot approve their own change; an indicator the agents suggest follows the same route.
What happens if a feed is late on the first live morning?
The Feed Steward agent marks every value that depends on it as Stale, keeps the last good value with its time, never fills the gap with an unmarked estimate, and re-runs the indicators when the file arrives. Proving that behaviour is one of the week-three tests, so the first live morning is not the first time it happens.
Can a smaller bank use liquidity risk management software?
Yes, but it should ask whether the daily explanation pays for itself. The policy statement scales expectations to complexity, and the FDIC's manual allows non-complex community banks in sound condition to forecast short-term positions monthly; the stronger case is a bank with concentrated or uninsured deposits, where a run can start in one sector.