The Risk Sits in the Process, Not the Payment

By: Mel Sutton, ALTALLO - Founder

Published: 2026-05-11 · Read time: 6 min · Category: Operations & Treasury Technology

David Harper, Founder & CEO of Dashro Solutions, on why high-volume payment operations are still largely manual, and what that quietly costs the firms running them.

[HOST]: Most finance teams will tell you their payment process works. What does that actually mean in practice, and where does the gap usually sit?

[GUEST]: When a finance team says it works, they normally mean it has not failed visibly yet. That is a different statement. The operational risk in manual, high-volume payment workflows tends to be quiet and cumulative. It does not show up on a dashboard. It shows up the day something goes wrong, and by then you are already dealing with a client conversation, a compliance question, sometimes a regulator.

[HOST]: So what is Dashro actually solving for?

[GUEST]: Organisations processing meaningful payment volumes every day, wealth managers, brokerages, payment providers, are still running those workflows on a combination of manual instruction, email approvals, and end-of-day reconciliation done by a person. It works, until it does not. An error at scale is not a minor inconvenience. It is a client relationship, a compliance event, occasionally a regulatory one.

It persists because the risk is invisible most of the time. The process did not fail today, so nobody examines it. What we see consistently is that the exposure is structural, not incidental. By the time it becomes visible, it is already expensive.

[QUOTE]: The process did not fail today, so nobody examines it. By the time the exposure becomes visible, it is already expensive.

[HOST]: How does the platform actually work, and what does it replace?

[GUEST]: It replaces the manual layer entirely. The system connects to the client's existing banking relationships via API, integrates with their back-office, and automates the full payment workflow, from instruction and approval through to execution and reconciliation. We do not displace banking relationships or governance. The automation sits over what is already there.

After deployment, treasury and operations keep full oversight. They are not removed from the process. They are removed from being the process. That distinction matters.

[HOST]: Visibility is a recurring complaint we hear about payment workflows. How does Dashro handle that?

[GUEST]: Every payment can be made completely visible across the organisation, or restricted by user, group, client, or any other dimension the firm wants to define. The practical effect is a significant reduction in email traffic. People stop having to ask why a payment was rejected for authorisation, or where it currently sits in the chain. The status is on the screen. If something is still with compliance, the user knows that, and they know who to chase. That alone removes a meaningful amount of internal noise from the day.

[HOST]: And the operational time saving for treasury and operations teams?

[GUEST]: Substantial. Most firms in this space have people logged into multiple banking portals and back-office systems simultaneously, just to confirm whether an instruction has gone through. Dashro confirms the status of the payment instruction and the completion of the payment itself, with email or Microsoft Teams alerts. Teams stop living across half a dozen tabs. The time recovered is not marginal.

[HOST]: How rigid is the workflow? Firms structure approvals very differently.

[GUEST]: It is extremely flexible. Workflows and authorisations are entirely user-defined. A user group is assigned to a status in the payment lifecycle. When a payment hits that status, that group can authorise it. Payment types, statuses, and the workflow itself are all configured in the system and can be adjusted at any time. Firms keep full control. We are not asking anyone to bend their governance to fit our software.

[HOST]: What about cash management itself?

[GUEST]: The platform has its own cash balance management built in. For firms that prefer to drive cash management from their back-office system, we can take feeds from there as well. Both models work. It depends on where the firm wants the source of truth to sit.

[HOST]: How quickly can a firm be operational?

[GUEST]: The base system installs in a day. It is SWIFT-ready out of the box. For a firm that wants to make payments through SWIFT with no changes to back-office systems, we can have them live within two weeks, from first conversation to live payments.

Timelines extend in two situations. The first is when additional bank API connections are needed for relationships we do not yet cover. The second is when back-office integration is more involved. Both get scoped and costed before any work begins. There are no surprises mid-engagement.

[HOST]: Once it is live, how involved is your team day to day?

[GUEST]: Minimal. The platform is fully automated and has been reliable in production. We get a low volume of support calls. That is not an aspiration, it is what we observe across the existing client base. Day to day, we are not in the client's operations. We monitor and we are available. That is it.

Where we do step in is payment exceptions and errors, and we handle those when they arise. The day to day is not ours. The autonomy is the point.

[HOST]: Who is using it today, and where do you see the strongest fit?

[GUEST]: Existing clients are mainly wealth managers, brokerages, and smaller banks. The common thread is not sector. It is payment volume, and the consequence of getting it wrong. Any firm processing multiple payments daily, where accuracy and timing carry material consequence, is the right profile.

Our largest client uses Dashro as their primary payment infrastructure and also runs payroll through it for around sixty employees a month. That breadth is deliberate. The platform is not built for a single payment type. It is built for organisations that need reliable, automated execution across whatever they are moving.

[QUOTE]: The common thread is not sector. It is payment volume, and the consequence of getting it wrong.

[HOST]: How is the commercial model structured?

[GUEST]: A one-off implementation fee covers the product and full installation. After that, a monthly support retainer is agreed based on the complexity of the customisations in place. There are no per-transaction charges and no costs that scale with volume. The fee structure is fixed and agreed before work starts.

An initial scoping call, normally thirty minutes, is enough to establish requirements, integration scope, and a full cost outline. Nothing proceeds until that picture is clear on both sides.

[HOST]: How does Dashro differ from other tools in the space?

[GUEST]: The meaningful difference is back-office integration. Most comparable offerings handle the payment layer. Ours goes further, into the back-office systems that sit behind the payment, where the operational complexity and the bulk of the manual effort actually live.

For organisations where the payment itself is only part of the workflow, where something has to happen in a portfolio system, a CRM, or a reconciliation tool after money moves, that depth of integration is where the comparison diverges materially.

[HOST]: Final question. If a CFO or COO reading this recognises their own setup in what you are describing, what is the right next step?

[GUEST]: A short conversation. Thirty minutes is enough for us to understand the volume, the bank relationships, the back-office, and where the manual effort sits. From there we can give a clear view on scope, timeline, and cost. No commitment, and no work begins until both sides are comfortable with the picture.