.jpg)
When a community bank loses a deposit, the instinct is to blame the rates. “We could never compete with Online Bank’s rates” is the easy, but often incomplete, explanation.
Most banks never actually check whether a lost deposit was a pricing loss or a friction loss. It's simpler to assume the money went to whoever offered a better number.
Deposits have never been easier to move than they are today. With only a few clicks of a button, thousands of dollars can be transferred to a competitor, practically in an instant. What now holds those deposits in place must be something more substantial than rate alone.
An increase in digital tools being added to the bank’s tech stack can also result in an increase in dead-ends when those tools don’t work seamlessly together.
When a new account is being opened and the bank is conducting its KYC process and connecting external accounts, sometimes those identity checks fail. It could be for reasons beyond fraud, like name mismatches, address errors, or because whatever tool is being used just didn’t verify the link correctly. Once an error hits, and there’s no clear immediate resolution, the customer is left having to either call support or give up and try elsewhere.
When there’s no option to continue the account opening and come back to fund later (whether through a wire transfer, mailed check, or a second attempt at linking), the whole application has failed. Here, the account was basically won but ultimately lost due to a technical hiccup which could’ve been side-stepped.
Having the fewest possible steps between intent to open an account and the funding of the account can be equally as impactful as beating a competitor’s APY.
Being consistent and trustworthy with the information the bank is providing at the time someone is ready to act is just as important as whether the rate is competitive.
For many banks, public-facing rate updates are a manual process. There may be lags in updating or mismatches across the website, what’s programmed into the core, and the printed rate sheet sitting on a banker’s desk.
When a CD’s APY isn’t locked in at the moment the deposit account is funded it can lead to confusion, complaints, or disputes when it does finally get signed for.
If systems are disjointed, post-opening steps will be too. Adding beneficiaries, setting up joint accounts, and handling new account documents manually creates even more unnecessary friction and slows down time-to-funded even more.
If there is additional slowness post-opening, the account takes longer to become useful to the customer, becoming a reason in itself to abandon it or reconsider whether they should move money there. The speed at which the account becomes fully useful matters as much as the speed at which the account can be opened.
After an account is opened, the confirmation of funding and the writing to the core must happen in the same motion, not in two separate steps that can become out of sync.
Instead of a delayed batch process that occurs hours later or the next business day, real-time funding confirmation allows both the bank and customer to confirm that the money has landed, now. Similarly, this fact is also written to the core at the same time, not queued to be updated at a later time.
Linker's platform is built on this premise: the friction described is what happens when funding, core writes, and activation are treated as separate systems instead of one. Closing those gaps is the design problem we’re solving.
While the rate wars can seem like the problem on paper, the funding gap may be the problem actually costing the deposit.