When a bank transaction posts, how does the system know which forecasted event it matches? Centinel scores each transaction on four signals to find out.
March 15, 2026
A $142.37 debit posts to your checking account on March 11th. The merchant name in your bank feed reads "AMEREN IL ELCTRC." Your forecast has a $150 electricity payment scheduled for March 10th. Is that the same event?
Probably. It's the right general category — a utility payment. The amount is close. The timing is one day off. But "probably" isn't the same as "definitely." The amount doesn't match exactly. The date is a day late. And the merchant name in the bank feed is an abbreviated string that doesn't obviously correspond to the plain-English "electricity" label you used when you set up the event.
Now consider that this determination needs to happen not just for your electricity bill, but for every transaction that posts to your account — your paycheck, your rent, your car payment, your subscriptions, your credit card bill — potentially dozens of events per month. Some will be obvious matches. Others will be ambiguous. And the system making these determinations can't pause and ask you about every single one, because the whole point of automation is to reduce the work you have to do, not create a new stream of questions to answer.
This is the transaction matching problem: given a bank transaction that just posted, determine which forecasted event it corresponds to — if any — with enough confidence to act on the answer. It's one of the core mechanisms behind how a checking account cash flow forecast actually works — and a key part of the broader practice of maintaining that forecast over time. Without it, every new transaction would require manual attention. With it, the routine cases are handled automatically, and your attention is directed only to the cases that actually need human judgment.
Transaction matching in bank accounts might sound like a niche problem, but it's actually one of the most well-studied challenges in financial technology. Corporate treasury management systems face this exact problem every day when reconciling bank statements against forecasted cash flows. The industry-standard approach is confidence-based automated matching: score each bank transaction against expected cash flows using multiple signals, assess confidence, and route accordingly. Centinel applies this same methodology — refined over decades in corporate cash management — to consumer checking accounts, where the same fundamental challenge exists at a smaller scale.
When Plaid delivers a new bank transaction to your checking account cash flow forecast, Centinel's matching algorithm scores it against every eligible saved event in the user's forecast. The score is a composite built from four distinct signals, each measuring a different dimension of similarity between the transaction and the event.
The most intuitive signal. How close is the transaction's dollar amount to the event's expected amount? An exact match — your rent is $1,500 and the transaction is exactly $1,500.00 — is a strong signal. A small variance — your electricity bill is $142.37 against a forecast of $150 — is still a meaningful signal, because many recurring expenses vary slightly month to month. A large variance — the transaction is $500 and the forecast expected $150 — is a weak signal.
The strength of this signal depends partly on the nature of the event. Some expenses are inherently fixed-amount: your rent, your car payment, your mortgage, most subscription services. For these events, even a small amount discrepancy is informative because the amount almost never changes. Other expenses are inherently variable: your electricity bill, your water bill. For these, moderate variance is expected and the signal needs to be calibrated accordingly.
How close is the transaction's post date to the event's expected date? A same-day match is the strongest signal. One or two days off is common and still meaningful — bank processing delays, weekends, and holidays routinely shift when transactions actually post relative to their scheduled date. Several days off is a weaker signal, though still potentially relevant for events that have inconsistent timing.
Some events post with high date consistency. Direct deposit payroll, for instance, tends to arrive on the same day every pay period (or one day earlier when the scheduled date falls on a weekend or holiday). Other events are less predictable — utility billing cycles can shift by a few days.
Does the merchant description in the bank transaction match what Centinel has learned for this event? This is a powerful signal when it's available, but it comes with a significant caveat: it's not always clean.
Bank transaction descriptions are notoriously inconsistent. Your electric utility might appear as "AMEREN IL ELCTRC" in one transaction and "AMEREN ILLINOIS" in another. Your gym membership might post as "ABC FITNESS CENTER" or "ABC FIT CTR" or just "ABC FIT." ACH debits, bank transfers, and direct deposits often have generic or cryptic descriptions that don't map to any recognizable merchant name at all. This messiness is a fundamental feature of bank feeds — it's how banks encode transaction information, and it varies by institution, payment method, and transaction type.
How much merchant data Centinel has for a given event depends on how the event was created. Events that were identified through Centinel's recurring transaction detection during onboarding — where the system analyzes your recent bank history, identifies patterns, and you confirm them — come pre-populated with merchant data from the transactions that were used to detect the pattern. These events have a rich starting profile from day one. Events that were added manually by the user — typing in "Electricity — $150 — 10th of each month" — start with no merchant data. For those events, the merchant signal becomes available after the first confirmed match, when Centinel stores the merchant string from the bank transaction and uses it for future matching.
Plaid assigns automated categories to transactions (utilities, payroll, transfer, etc.). Like merchant name, this signal's availability depends on how the event was created. Events detected during onboarding already have category data from the bank transactions that identified the pattern. Manually-added events start without category data and accumulate it after confirmed matches.
This is a supporting signal rather than a primary one. Plaid categories are useful for confirming a match that other signals have already suggested, but they're not specific enough to drive a match on their own. Many different events might share the same category (e.g., all your utility bills are "Utilities”), so the category signal helps narrow the field but rarely identifies a unique match.
Centinel's algorithm evaluates all four signals and produces a composite confidence score for each transaction-event pair. The critical design choice is in how the signals are weighted.
Amount and date are the primary signals. These are always available — every event has an expected amount and a scheduled date — and together they can produce enough confidence to resolve a match even without any merchant or category data. Merchant name and category are secondary signals that add confidence when available. For events detected during onboarding, all four signals are typically available from the start, which means these events tend to match with high confidence immediately. For manually-added events, the secondary signals accumulate over time as matches are confirmed.
Not every event enters the system with a full signal profile. When a user manually adds an event to their forecast — because Centinel's onboarding detection missed it, because it's a new obligation that doesn't appear in the bank history yet, or because the user is adding an event for a bill paid from a different account — that event starts with only amount and date information. No merchant name, no category, no amount variance history. This is the cold start: the event exists in the forecast, but the system hasn't yet observed how it manifests in the bank feed.
Centinel's design choice for cold start events is that amount and date alone can carry enough weight to produce a confident match. If you manually add your rent as $1,500 on the first, and a $1,500.00 debit posts on the first, that's a strong enough combination to match automatically — even without any merchant data. The system doesn't need to know that the transaction description reads "ONLINE PMT PROPERTY MGMT." The amount and date alignment is sufficient.
This matters because the alternative — requiring merchant data before any auto-matching can occur — would mean every manually-added event needs at least one month of manual confirmation before automation kicks in. By allowing amount and date to carry the match on their own, Centinel can auto-resolve many manually-added events from their very first occurrence.
The tradeoff is precision in ambiguous cases. Without merchant and category signals, the system has fewer tools to disambiguate when multiple events have similar amounts and dates. If you manually add two expenses that are both around $50 and both scheduled for mid-month, the system might not be able to tell them apart on amount and date alone. In those cases, the transaction goes to the user for review — the system is being honest about its uncertainty rather than guessing. After that first confirmed match populates the merchant data, the ambiguity resolves, and subsequent months auto-match cleanly.
The cold start period is real but temporary and limited in scope. Events detected during onboarding — which typically represent the majority of a user's recurring cash flow — skip cold start entirely because they already have merchant and category data. Only manually-added events go through the cold start cycle, and even among those, events with distinctive amounts and dates (like a $1,487 rent payment on the first of the month) often auto-match immediately. The events most likely to need that first manual confirmation are the ones that (i) share similar amounts and timing with other events, or (ii) post on different days or in different amounts than what the user saved — and once that single confirmation occurs, the learning loop handles the rest.
The composite score from the four signals determines how each transaction is handled. Centinel routes every transaction into one of three tiers based on its confidence level.
When the combination of signals produces a score above the auto-match threshold, Centinel links the transaction to the event without asking the user. The match is recorded, the event is confirmed as having occurred, the actual amount is captured (even if it differed from the estimate), and the forecast recalculates accordingly. The user never has to think about it.
This is the ideal state and where the majority of transactions should land for an established user. Your rent — same amount, same date, same merchant every month — auto-matches silently. Your direct deposit paycheck — same amount, same day, same source — resolves without prompting. Even events with moderate variance, like a utility bill that fluctuates by $10 to $20, will typically auto-match once the system has learned the merchant name and amount range from previous cycles.
When the signals produce a score above a minimum threshold but below the auto-match threshold, the transaction lands in Centinel's reconciliation queue with a suggested match. The system is saying: "I think this transaction corresponds to this event, but I'm not confident enough to act on my own."
The user sees the bank transaction details alongside the suggested event and can confirm the match, redirect it to a different event if the suggestion was wrong, or take other actions. This is the human-in-the-loop layer — it keeps the user in control for ambiguous cases while minimizing effort, because confirming a suggestion takes seconds compared to manually searching through your event list to find the right match.
Transactions land here for several common reasons. The amount might be further from the estimate than usual (your utility bill was $200 higher than last month). The date might be more than a day or two off. The event might be a manually-added one still in cold start, where amount and date alone aren't strong enough to reach auto-match confidence. Or there might be multiple plausible candidate events with similar profiles, and the system can't confidently pick one over the other.
When the signals are too weak to even propose a match, the transaction goes to the reconciliation queue with no suggestion. This typically means one of three things: the transaction is a one-time charge that doesn't correspond to any saved event (a restaurant meal, an ATM withdrawal, a one-time purchase); it's a new recurring charge the user hasn't added to their forecast yet (a new subscription, a new bill); or it's an existing event that looks very different from what was expected (a dramatic amount change or a significantly shifted posting date).
The user reviews the unmatched transaction and decides how to handle it. If it's a one-time charge, they can dismiss it — the transaction is marked as reconciled with no event association, and the forecast isn't affected beyond what the balance already reflects. If it's a new recurring pattern, they can create a new event directly from the transaction, which seeds the new event's matching profile with the transaction's data so that the next occurrence is more likely to match automatically.
Every confirmed match — whether auto-matched by the system or confirmed by the user from the reconciliation queue — teaches Centinel something about what that event looks like in the bank feed. The merchant string gets stored or updated. The Plaid category gets recorded. The actual amount gets added to the event's variance history.
This creates a compounding improvement cycle. A manually-added event that needed user confirmation in month one (because it had no merchant data) now has merchant name and category populated from that first confirmation. In month two, the same event scores against all four signals instead of just two, and auto-matches without prompting. By month three, the event has multiple months of amount history, and the system's understanding of its normal variance is well-calibrated.
The learning loop also works in reverse. If the user corrects a match — redirecting a transaction from the wrong event to the right one — the system learns from the correction. The incorrectly matched event's profile isn't updated with misleading data, and the correctly matched event's profile is strengthened. Over time, this self-correcting feedback loop means the system increasingly reflects the user's actual financial patterns rather than just initial estimates.
The practical result is that Centinel's matching becomes less visible the longer you use it. In the first month, you might see several items in the reconciliation queue as the system learns your patterns. By the second or third month, most transactions auto-match silently, and the queue contains only genuinely new or unusual items that warrant your attention. The system is doing more work, but you're seeing less of it — which is the point. The matching algorithm exists to automate the routine comparison between forecast and reality, so your maintenance effort focuses on the decisions that actually require human judgment rather than rote transaction-by-transaction review.
The matching algorithm is the mechanism that closes the loop between what your forecast predicted and what actually happened in your bank account. When matching works well, every routine transaction is automatically linked to its corresponding event, amount differences are detected, and the forecast continuously recalibrates based on real data. The forecast becomes a living model of the user's actual financial patterns — not a static projection based on estimates that were accurate when first entered but have since drifted.
When matching doesn't exist — as in a spreadsheet forecast or a manual-only tool — that comparison depends entirely on the user. Every transaction requires human attention. Variances go unnoticed unless the user catches them. New patterns aren't flagged. And over time, the gap between what the forecast shows and what's actually happening in the account widens silently, undermining the reliability of the projections you're relying on to (i) make spending and savings/investment decisions, and (ii) prevent overdrafts.
Transaction matching is what turns a connected bank feed from raw data into actionable forecast intelligence. It's the difference between knowing that 47 transactions posted to your account this month and knowing exactly which of your forecasted events those transactions correspond to, where the amounts differed, and what needs your attention. That translation — from raw transactions to structured forecast feedback — is the foundation that Centinel's reconciliation system builds on, and it's what makes automated forecast maintenance meaningfully different from doing everything by hand.
STAY A STEP AHEAD
