Fintech SDR Discovery for Treasury Access Reviews

A fintech SDR will eventually call your treasury team and ask how you run access reviews. If the call turns into a checklist about your security controls, you shut it down fast, and you are right to. But if it stays on your actual workflow, who gets the list, who confirms a change is still needed, what happens when an answer comes back incomplete, you can answer honestly without exposing anything sensitive. Knowing the difference ahead of time is what makes this conversation worth having instead of one more call you cut short.

Why This Conversation Goes Wrong

Most vendor calls before this point have been generic and pushy, so when an SDR asks a specific process question, treasury tends to react in one of two ways. Either you go quiet and give one word answers that end the call early, or you overcorrect and describe internal weaknesses in detail to prove you take the topic seriously. Both responses cause problems. Going quiet kills a conversation that might actually be worth having, since a real tool evaluation never gets off the ground. Oversharing hands a stranger detail about who approves access changes and how gaps get caught, information you would never put in an email to someone you just met. The root problem is that this call gets treated like an audit when it is really a workflow question. A competent SDR wants to understand the mechanics of your review, not the strength of your defenses. Once you separate those two things in your own head, you know exactly how far to go before you stop talking.

How to Prepare

Before a discovery call, get clear internally on three things. Who receives the roster when a review period opens, who has the authority to confirm whether a role change should trigger an access change, and what your team actually does when an answer comes back incomplete. Write the sequence out in one or two plain sentences, the kind you would say out loud to a colleague, not the kind that belongs in a compliance document. If your quarterly review slows down for a specific reason, name that reason before the call happens. Maybe it slows down when someone changes departments and the system does not flag the change automatically. Maybe it slows down because the business approver takes a week to respond to a request. Naming the actual friction point in plain language gives the SDR something real to respond to, and it keeps the call moving instead of circling the same vague ground twice.

Decide in advance what you will not discuss on a first call. System names, specific tooling, and any detail about how an exception might get missed, none of that belongs in an early conversation with a vendor you just met. You can describe the shape of your process without describing the seams someone could exploit.

What to Say

An SDR opens with a plain question. "Walk me through what happens when your quarterly access review turns up a name you don't recognize as an active user anymore," she asks. You do not need to defend your setup, you just describe the steps. "HR sends us the current roster. The department lead confirms whether that person still needs the access for their current role. If they don't, an administrator removes it once we get sign off." The SDR follows up on the part that actually matters to her. "When someone changes teams partway through a quarter, does the roster catch that right away, or does it wait for the next cycle?" You tell her the truth. "It waits for the next cycle unless someone flags it manually, and that's usually where we lose time." A good SDR stops there. She does not push for detail about how often that gap gets missed or what happens when it does not get caught in time. Instead she might ask one more question. "Would it help to talk through that gap with whoever owns the roster and whoever signs off, so we can see where the delay actually sits?" That is a fair invitation. It asks about ownership and timing, not about your exposure.

If your process runs smoothly and you say so, a competent SDR accepts that and moves on, because there is no problem to build a pitch around. If you describe the same delay happening every quarter, expect a reasonable follow up question about whether a short conversation with the roster owner and the approver would be worth having. You can say yes or no to that without committing to anything bigger than a conversation.

Mistakes to Avoid

1. Do not assume every question is a test of your security. A plain question about who confirms an access change, answered calmly, sounds routine. The same question answered with a defensive speech about layered controls and encryption sounds like you have something to hide, even when you do not.

2. Do not hand over detail nobody asked for. If the SDR asks who confirms a role change, answer that question. Do not also walk through your escalation matrix, your audit committee's makeup, or your backup approval chain.

3. Do not let vague language stand in for facts. Saying "we have a formal process" without naming a single step answers nothing. It stalls the call and all but guarantees a second one covering the exact same ground.

4. Do not agree on the spot to a working session involving detail you have not thought through. If someone asks you to walk through your roster or your approval log live, that is a bigger commitment than a discovery call, and it is fine to say you will follow up once you have looped in the right person.

How to Practice and Score It

A treasury operations manager can run this exact scenario with a new analyst before that analyst ever takes a real vendor call. Set an AI counterpart to open with an ordinary process question, then push once when it hears a vague answer, the same way a competent SDR would. Score the analyst on three things. Did they name the specific trigger event, such as a department change or a completed audit cycle. Did they name who actually owns the decision, rather than saying "the team." Did they stop at the workflow and avoid describing control weaknesses nobody asked about. An analyst who can pass that scenario cleanly is ready for the real conversation, and usually realizes that habit, not any actual policy, was what made these calls harder than they needed to be.

This kind of rehearsal works the same way across financial services more broadly. The Financial Services practice conversations built for this industry let people from different roles prepare for the exact wording they will hear, rather than a generic version of the conversation. The same discipline shows up in Implementation Managers Building a Cutover Communication Planwhere naming the precise sequence of a cutover matters more than sounding confident, and in Implementation Managers Getting Dashboard Acceptance From the Right Userswhere getting the right person into the room decides the outcome as much as the message does. DealSpeak scores this same way, on specifics named and boundaries held, not on how polished the delivery sounds.

Where This Gets You

A workflow question answered plainly builds trust faster than any control detail ever will. Handle a handful of these calls well and vendor conversations stop feeling like audits, on either side of the table. That is the whole reason for separating the process question from the security question in the first place.