A security engineer's teardown of payment release in AP and spend platforms
Product roadmaps in accounts payable software have pointed in one direction for a decade: fewer clicks between an invoice arriving and money leaving. That is a genuine productivity gain and it is also, precisely, the removal of the control surface.
Where does payment release actually happen in AP and spend platforms?
At an API call authenticated by a session or a key. Platforms such as Bill.com, Ramp and NetSuite compete on removing seconds from the release path, and every second removed is a second removed from the confirmation gate. The approval record they produce is application state.
- Evaluate release mechanisms on five properties rather than on feature lists: what is rendered, what is bound, who can bypass, what evidence persists, and what automation inherits.
- Every platform in this category makes the same tradeoff differently, and none of them publishes it in those terms.
- The questions in this article are the ones to put to a vendor in a security review — they are answerable and rarely asked.
Part of Payment release authorization
Why a feature comparison is the wrong instrument
Vendor comparison content in this category lists capabilities: approval workflows, multi-level routing, mobile approval, MFA support, audit logs. Every platform has all of them, so the comparison discriminates on nothing that matters.
The questions that discriminate are architectural, and they are not in any datasheet. This article gives you five, with the shape of a good and a bad answer for each.
Property 1 — What is rendered at release
At the moment of final release, which fields are on screen, in full?
| Answer shape | Interpretation |
|---|---|
| Vendor name, amount, reference | Weak — the account is not shown, so the approval cannot cover it |
| Above plus masked account | Weak — masking conceals the substituted portion |
| Above plus full account, routing and beneficiary bank | Adequate |
| Above plus a prominent flag where details changed since last payment | Strong |
Ask to see the actual release screen on the actual device your approvers use, including mobile. Mobile approval screens are consistently the weakest and are where most approvals happen.
Property 2 — What the approval is bound to
Is the approval bound to the payment's content, or to a payment record identifier?
The test question: if an administrator changes the beneficiary account after approval and before release, does the approval remain valid?
If the answer is yes — and in most platforms it is — the approval is bound to a record, not to content. Ask what happens instead: does the platform reset approvals on material field changes, and which fields count as material?
Property 3 — Who can bypass
Every platform has an override. Ask three questions about it:
- Which roles can release a payment without the configured approvals?
- Can a platform support engineer, on the vendor's side, perform that action?
- Is the override recorded distinctly from a normal release, and is that distinction visible in an export?
The second question is the one that surprises people and the one vendors answer least comfortably. Support access to customer tenants is normal and necessary; whether it can release payments is a separate question.
Property 4 — What evidence persists
Assume you need to demonstrate, two years from now, that a specific payment was approved by a specific human who saw specific details.
| Available evidence | Strength |
|---|---|
| An audit log entry with user id and timestamp | Weak — entity-produced, mutable at the database layer |
| An exportable approval report | Weak — same |
| A screenshot the client captured | Weakest |
| A signed artefact verifiable without the platform | Strong |
Also ask how long approval detail is retained, and whether it survives a plan downgrade or a contract termination. Several platforms retain payment records longer than they retain approval detail.
Property 5 — What automation inherits
Auto-approval rules, recurring payments and API-initiated payments all bypass the interactive path by design. Ask:
- What conditions can trigger auto-approval, and who can configure them?
- Does an API key alone create and release a payment, or is a separate authorisation required?
- Do recurring payments re-validate beneficiary details against the original authorisation?
- Is there a ceiling on automated payments, and is it enforced server-side?
The third is where recurring vendor payments become a durable exposure: an authorisation given once, inherited indefinitely, against beneficiary details that can change.
How to use this
Send the five properties to your shortlisted vendors as written questions before the demo. Answers in writing are materially more informative than answers in a call, and the pattern of which questions get deflected is itself the finding.
This article deliberately does not score named products. Release behaviour changes between releases and between tenant configurations, and a scored table would be stale within two quarters and wrong for half of readers. The questions do not go stale.
What a security engineer should actually compare
| Question | Why it matters |
|---|---|
| What authenticates the release call? | A session, a long-lived key, or a fresh per-action assertion |
| Is the beneficiary change gated differently from the payment? | The change is where the loss starts |
| Is the account number masked on the approval screen? | Masking conceals exactly the digits an attacker substitutes |
| Can a third party verify an approval without calling the platform? | Decides whether evidence survives the relationship |
| What is releasable in 24 hours with no human approval? | The number that sizes everything above |
The masking question deserves emphasis. Truncating account numbers on approval screens was borrowed from consumer banking interfaces, where it protects the customer. In an approval context it hides the field the attacker changed.
Objections and honest limits
“Zero-click automation is the product.” It is, and for most invoices it is correct. The argument is about the tail: beneficiary changes, first payments to a new payee, and amounts above a threshold. That tail is a small fraction of volume and most of the loss.
“Dual approval already covers us.” Two approvals in one platform are two rows written by one system, and one adversary-in-the-middle kit can hold both sessions. Independence is the property you want, not a second click.
Evaluating a spend platform as a security engineer
- Attempt a beneficiary bank change. Observe exactly what gates it, and what the record afterwards contains.
- Read the approval screen carefully. Is the full account number shown, or truncated?
- Export an approval record. Decide whether it would satisfy an auditor without trusting the platform.
- Enumerate the API surface for release. And what authenticates it.
- Compute the 24-hour exposure. With no human in the loop, under current settings.
Terms used here
- Release
- The irreversible step where funds leave. Distinct from approval, and frequently authenticated differently.
- Beneficiary master data
- The stored payee record including bank details. Changing it redirects every future payment, which is why it is the real target.
- Straight-through processing
- Automated handling with no human touch. Correct for most invoices, and the thing that must have a bounded exception set.
Frequently asked questions
Why not name and score the platforms? Release behaviour varies by version and by tenant configuration, so a scored table would be inaccurate for many readers and stale quickly. The questions are durable; the scores are not.
Which property matters most? Property 2 — whether the approval is bound to content or to a record identifier. It determines whether post-approval alteration is possible, which is the highest-consequence failure.
Is mobile approval inherently weaker? In practice yes, because the screen renders less. If most of your approvals happen on mobile, evaluate the mobile screen rather than the desktop one.
What if a vendor will not answer in writing? That is an answer. Security reviews that accept verbal assurances on architectural questions are not security reviews.
Are spend platforms insecure? No. They are optimised for throughput, which is what customers buy. The question is whether the tail of consequential changes is gated differently from the routine flow.
What is the highest-value control to add? Gating the beneficiary bank detail change, not the payment. The change is where the diversion starts.
Why does account masking matter? It conceals the digits an attacker substitutes, so the approver compares two masked strings that look identical.
Where this fits in Manav
Manav sits on the release endpoint and on the beneficiary change endpoint, renders the full account details and the delta from what was on file, and binds the approver's signature to that exact payload.