Slash: why business banking is moving to messages
At the end of 2022, Slash lost its biggest customer segment in a matter of months. The company had found early traction issuing virtual cards to sneaker resellers: thousands of high school and college kids entering raffles, each raffle requiring its own card. Then the Yeezy line unraveled, the sneaker resale market cratered, and the demand underneath the business went with it.
Slash rebuilt around horizontal business banking for SMBs and mid-market companies, and it worked. Now, Slash processes over $1 billion in transaction volume per month.
We sat down with Kevin, Slash's co-founder and CTO, to ask what’s next? He did not describe a screen. He described a message thread.
In this post we'll walk through how Slash got there: the users their dashboard was never built for, what a check deposit looks like when it happens inside a text conversation, the four ways this approach fails, and why the timing changed in 2026.
The half of the user base that never logs in
Every business banking product has two subsets of users who have different needs.
First are owners and finance teams. They live in the web dashboard. They reconcile transactions, set budgets, pull statements, and issue cards.
The second is everyone else, the field employees, contractors, and operators who hold the cards and spend the money. They almost never open the product & don’t want to. Many never install the app.
This is not a UX problem. A technician on a job site is not going to open a banking app to check a remaining budget before buying a part. He is going to buy the part and deal with logging it later. The field user only cares about the card working and easily logging the expense.
With a message thread, there is nothing to install, the channel is already open, and it is already where that user spends the working day. Kevin's framing: with real two-way messaging and agents behind it, "you can get insights over all of your finances, perform every single action you perform on the web, just through iMessage."
What text messaging could already do, and what it couldn't
Banking products have used text messaging for years, almost entirely as a one-way notification rail. Your card was charged. Your balance is low. Reply STOP to opt out.
Kevin described the ceiling plainly: "Traditionally, products using some SMS type of interface, we're used to collecting receipts and maybe submitting reimbursement requests. And that was about it."
Two constraints held the channel there.
The first was the channel. SMS moves text one direction at a time with no reliable notion of a thread, no read state, and no indication that anything is happening on the other end. It’s just a delivery mechanism.
The second was that nothing behind the channel could act. An inbound message has to be turned into an intent, matched to a cardholder, checked against permissions, and executed against core banking systems. Doing that with hand-written rules meant innumerable decision tree style logic for every phrasing and use case, which is why the feature set stopped at receipts. Agents
Both constraints moved as a resume of iMessage and agents. Slash's bet is that with AI agents on the back end, solving the channel constraint is now ads value.
A deposit, start to finish
Take the most ordinary item on Kevin's list. A field employee gets handed a paper check.
The current path is five steps and a delay: photograph the check, find the banking app, log in, navigate to deposits, photograph it again inside the app. Realistically the check sits in a truck console for a week first.
The thread version is one step. Photograph the check, send it to the number already saved in the phone, get a confirmation back.
On Slash's side, the inbound message arrives as a signed webhook. The payload carries the sender, the chat, and the photo as a media part:
{
"event_type": "message.received",
"webhook_version": "2026-02-03",
"event_id": "2915e81c-5068-4796-ace2-21d2c94ad298",
"data": {
"chat": { "id": "8f392755-6865-4b18-880a-227f9d8b458f", "is_group": false },
"direction": "inbound",
"sender_handle": { "handle": "+12025559876", "service": "iMessage" },
"parts": [
{ "type": "text", "value": "check from the Ramirez job" },
{
"type": "media",
"mime_type": "image/jpeg",
"size_bytes": 245678,
"url": "https://cdn.linqapp.com/attachments/a1b2c3d4/check.jpg?signature=..."
}
],
"sent_at": "2026-02-05T19:31:13.074Z",
"service": "iMessage"
}
}
An inbound iMessage delivered to your endpoint, with the photo attached as a media part.
From there it is ordinary backend work. Match sender_handle.handle to a cardholder, confirm that cardholder is authorized to deposit into the account, pull the image, run it through the same deposit pipeline the dashboard uses, and reply into the same chat.id:
curl -X POST https://api.linqapp.com/api/partner/v3/chats/8f392755-6865-4b18-880a-227f9d8b458f/messages \
-H "Authorization: Bearer $LINQ_API_KEY" \
-H "Content-Type: application/json" \
-d '{"message":{"parts":[{"type":"text","value":"Deposited $4,180.00 into Operating. Available tomorrow."}]}}'
The reply goes back into the same thread, so the user sees one continuous conversation rather than a notification.
Kevin gave two other examples. A cardholder submits a reimbursement at the moment of the expense instead of spending an hour batching a month of receipts. A contractor asks what’s left in a budget before spending and gets an answer in seconds.
None of these are new banking capabilities. All three already exist in the dashboard. Now, they are reachable by a user in their most native channel.
Why iMessage and not SMS
All of this technically works over SMS.
iMessage makes the interaction read as a conversation. Threading, so a follow-up question has context. Read receipts and typing indicators are how a user knows the system heard them before answering. Group chats are how operations teams already coordinate. And delivery in the channel people treat as personal rather than the one they associate with notifications and spam.
Messages carrying banking activity need encrypted infrastructure that’s inaccessible to the provider, which for Slash meant building on the only SOC 2 Type II certified iMessage API.
What to call it in front of users
The end user experiences in all of this is a text conversation.
In user research across this category, consumer-facing "AI assistant" language tests poorly and or sometimes negatively. Users do not want a copilot for their bank account. They want to text their bank and have it text back.
Where this breaks
Four failure modes, roughly ordered by how often they kill the project.
-
Conversion drops if messaging is added as a step inside an existing onboarding or approval flow. Users bounce between surfaces and never finish. iMessage is most effective as the primary way a given user reaches the product.
-
If a person texts in and waits thirty seconds, they give up. This is why low latency is critical. Delivery through Linq is under 120ms, so the remaining time belongs to your intent handling, your auth checks, and your core banking calls. Those are the parts that can easily take longer than thirty seconds if done incorrectly.
-
Not every workflow fits in text. Disputes, statements, and multi-step card configuration are better in classic UI. The agent has to recognize the boundary and push the user to the dashboard with a link, rather than attempting a dispute across five messages and producing a worse experience.
-
Compliance is a problem with most providers. Financial data raises the compliance requirement. That requirement tends to disqualify providers, after the prototype already works. Establish what your security review requires of the channel before you build on it.
Why 2026 and not 2020
Text was always the most available interface. Every user has it natively on their phone and it works on every device. The problem was that the thing on the back-end was incredibly complex to set-up. Agents changed that, and it is the reason a banking CTO is willing to describe a text thread as a primary surface rather than a notification channel. Kevin's forward-looking claim is the strongest statement in the interview: "As agents and AI get crazier, positioning Slash as the one place where your agents can access all your financial services and take actions on your behalf is going to be the norm."
Slash has started rolling its iMessage channel out to customers, built on Linq's iMessage API. Kevin's assessment of where it goes: "It'll only get better from here on out."
Principles
- Meet users in the channel they already trust.
- Design so the user never needs to open the app.
- Market the conversation, not the agent.
- Treat delivery and latency as product features.
- A conversation should be the primary UI for users of it.
