Daniel Wagner, Director of Product and Engineering at Q2 – Interview Series

Daniel Wagner, Director of Product and Engineering at Q2, is an experienced technology and product leader with a background spanning artificial intelligence, machine learning, data platforms, digital banking, and enterprise software delivery. Before joining Q2 through its acquisition of Sensibill, Wagner spent more than a decade at Sensibill, advancing through leadership roles including Delivery Manager, Delivery Director, Director of Engineering, and VP of Engineering. He led Data and AI teams developing machine learning projects, oversaw mobile solutions for major financial institutions, and most recently led engineering for a customer data platform focused on data enrichment and insights. Earlier in his career, Wagner co-founded and served as CEO of the Brazilian operations of Itelios, an application development company later acquired by Capgemini, after beginning his career as a software engineer. Q2 acquired Sensibill in 2022 to strengthen its data and machine learning capabilities for financial institutions.

Q2 is a financial technology company providing digital banking and lending solutions to banks, credit unions, fintech companies, and alternative finance providers. Its platform spans consumer, small business, and commercial banking, along with digital onboarding, embedded finance, relationship pricing, risk and fraud management, and data-driven personalization. Q2 is increasingly embedding AI across its product portfolio, including tools designed to improve banker productivity, detect fraudulent activity, personalize account-holder experiences, and help financial institutions make faster, data-informed decisions. The company serves more than 1,000 financial institutions across its broader portfolio and positions its technology as an infrastructure layer for helping financial institutions modernize and expand their digital services.

Your work at Q2 has focused on cyber resilience and how organizations prepare for and recover from security incidents. As financial institutions begin deploying AI agents that can take actions rather than simply analyze information, what new security risks concern you most?

Cybersecurity and fraud mitigation address different parts of the problem. Cybersecurity is responsible for “securing the perimeter,” including making sure the account access is guarded, and the underlying software is sound. My work picks up from there, once someone is already through that perimeter, and focuses on determining whether they are who they claim to be.

With the rise of AI agents, the person walking through that door is a delegated agent acting on someone else’s authority. The risk I’m most concerned about is prompt injection. That is when a fraudster manipulates a legitimate user’s agent into taking actions that the user never authorized, and that don’t serve that user’s interests. It is a new frontier of fraud that can create challenges to detect.

Banks have traditionally built identity and access-management systems around people, applications, and service accounts. Should an AI agent now be treated as a distinct identity of its own, and what would that mean in practice?

The clearest analogy comes from business banking, where delegated access is already a mature discipline. Businesses routinely grant employees limited access to handle specific tasks, such as viewing balances, without giving the full authority of the account owner.

Financial institutions should apply the same framework to AI agents. An agent should be treated the way a business treats a human assistant, a distinct identity with a defined, limited role. That means building identity and access management around narrowly scoped agent permissions from the outset, rather than granting agents the same standing as the account owner.

When an AI agent is acting on behalf of an employee or customer, how should a bank determine exactly what data it can access, which accounts it can interact with, and which financial actions it is permitted to execute?

Start with read-only access as the default. Banking already has the infrastructure to support this level of granularity, largely because business banking has required it for years. Financial institutions have the ability to be very precise about what an agent can see and do.

Initiating a transaction and approving one can be treated as separate permissions, and both can be scoped further by dollar amount or transaction type. Many institutions already rely on two-person approval cycles for business accounts, and that same workflow extends naturally to agents. An agent may initiate an action, but the final approval should remain with the account holder, keeping a person in the loop for anything beyond viewing information.

Least-privilege access becomes more complicated when an agent may need to perform dozens of steps across multiple systems to complete a task. How can financial institutions give agents enough authority to be useful without granting them excessive permissions?

No money needs to move for an agent to be useful.  Most of the value an agent provides comes from retrieving and organizing information, such as checking balances, tracking spending, or spotting trends. That doesn’t require elevated permissions and is largely why people log into their accounts in the first place. Anything beyond that, such as moving money or changing account details, belongs in a separate, more tightly controlled tier of authority.

Fraud systems are designed to identify suspicious human behavior, such as unusual logins or transaction patterns. How does fraud detection need to evolve when legitimate AI agents may themselves operate at machine speed and exhibit behavior that would look abnormal for a human user?

Some existing controls do rely heavily on transaction speed as a signal. Those signals will need to be recalibrated for a world where legitimate agents can also move quickly. That said, most of our behavioral signals, which look at what’s normal for a given user and a given payee, are still relevant for catching fraud. Financial institutions are able to evaluate behavior in addition to checking for identity.

In the future, financial institutions will need the power to dial detection sensitivity up or down depending on context, and to have the permissions and logging in place to tell a legitimate user’s agent apart from one being operated by a fraudster.

What happens if an attacker compromises an AI agent, manipulates its instructions, or tricks it into taking an unauthorized action? What signals could help a financial institution distinguish a legitimate autonomous action from a compromised one?

In this scenario, an agent doing something the user never asked it to do, often as the result of a prompt injection attack. However, the detection approach doesn’t fundamentally change. We’re still looking at behavior. An action that falls outside a user’s established patterns is a signal worth flagging, regardless of whether a human or an agent initiated it.

Money movement represents an especially high-risk use case. Where should banks maintain mandatory human approval, and are there transaction types or dollar thresholds where you believe autonomous agents should not be allowed to act independently?

Yes, limits are necessary. As mentioned previously, business banking offers a precedent that can easily be adapted for AI agents. Temporary approvals can allow an agent to initiate an action, but a human still has to review and approve it before it’s finalized.

In practice, that means setting thresholds on both the value of individual transfers and the number of transfers an agent can initiate within a given period. Mandatory human approval shouldn’t be limited to money movement alone, either. For example, changing payment details for an established, trusted payee can be just as risky as moving funds.

AI agents may increasingly interact with other agents operated by fintechs, vendors, customers, or other financial institutions. How does this expand third-party risk, and how can a bank establish trust when it may not control every agent participating in a financial workflow?

There are two scenarios worth calling out here. The first one would be the user granting an agent access to their account. This agent is acting on behalf of the user, and under that user’s authority. If they are allowing that agent to work under an Agent-to-Agent protocol, and working under the direction of other agents, then it’s the user who is assuming that risk. Everything is happening under their authorization, and the banks will not try to extend their responsibility.

The risk profile shifts when an institution builds or operates its own proprietary agent specific to its bank. At that point, the institution is taking direct responsibility for that agent’s behavior, which is different than honoring another party’s delegated access. Financial institutions will need to do their due diligence on any third-party agent they allow into a workflow, but some of that responsibility ultimately gets pushed back to the end user. The customer’s “circle of control” defines how far the institution’s obligation extends.

If an authorized AI agent makes an incorrect decision that results in a financial loss, data exposure, or fraudulent transaction, how should accountability be divided between the employee who delegated the task, the financial institution, the technology provider, and the agent’s underlying model?

Reg E, the federal rule that governs consumer protections for electronic transactions, still applies here. It sets the fraud liability limits and investigation requirements which banks operate under. Because of Reg E, a financial institution’s duty to investigate a disputed transaction doesn’t go away.

What does change is the underlying liability question. If a user has knowingly delegated access to an agent and that agent makes an incorrect decision, the institution’s obligation to reimburse the user for the resulting loss looks different than it would for unauthorized third-party fraud.

In effect, delegating that authority means the user is accepting some of the risk that comes with it. The institution is not going to assume liability that belongs to the account owner simply because the mistake was made by software rather than a person.

Looking ahead, what security and governance foundations should banks and credit unions put in place today before allowing AI agents greater autonomy over sensitive data, customer accounts, and financial transactions?

The single biggest opportunity is to bring the governance model that already exists in business banking over to personal banking. Business accounts have years of precedent in granular permissions, delegated access, and approval workflows built for exactly this kind of scenario.

Rather than building an entirely new framework for agent governance, banks and credit unions should look at what’s already proven to work on the business side and adapt those same controls, permission tiers, and approval structures for personal accounts.

Thank you for the great interview, readers who wish to learn more should visit Q2.