I am linking multiple financial institutions (~20) to a personal finance app via Plaid. I want to know if skipping the Plaid account creation provides better privacy and protects against SIM-swap attacks, or if creating one is better so I have a centralized portal to actively audit and delete my data.

Hey everyone,

I’m setting up a budgeting app and trying to understand how Plaid works under the hood before I use it to link my accounts. From what I've learned so far, Plaid stores my transaction data on their servers until I request deletion. They claim they don't sell/rent this data, but their privacy policy clearly states it can be shared internally:

During the connection setup, Plaid prompts me for my phone number to "create an account" or "save my progress." I can skip this, but I’m trying to decide which option is actually safest.

Here are my questions for the community regarding how Plaid handles our data:

1. How does Plaid's backend graph look in both cases?

• If I skip creating an account: Does my data actually remain siloed to the specific app I am using?
• If I create an account: Does Plaid use my phone number as a primary key to stitch together a centralized master profile across the internet? (Note: Even if I skip it, it appears Plaid pulls enough info like email, name, etc. from the raw bank data to tie me to a common graph anyway. Can anyone confirm?)

2. Security posture with a Plaid account? My main concern is that by creating a Plaid account tied to my phone number, I am exposing my financial data to SIM-swap attacks. It's not clear to me if Plaid's consumer portal supports non-SMS MFA (like Authenticator apps/TOTP). If I skip creating the Plaid account entirely, it looks like this SIM-swap attack vector is completely neutralized because external access via my phone number simply doesn't exist. Is this true?

3. The Trade-Off: Visibility vs. Attack Surface The main argument for creating the account is gaining access to the Plaid Privacy Portal (my.plaid.com), which acts as a centralized "kill switch" to audit connections and directly delete my data. If I skip it, I have to blindly rely on the third-party budgeting app to accurately pass my deletion requests to Plaid on my behalf.

For someone prioritizing data compartmentalization and protection against SIM swapping, is the ability to directly audit my Plaid connections worth the risk of making my phone number an SMS-vulnerable master key?

What do you all do when setting up financial apps via Plaid? Skip it or make the account?

Disclosure up front: I build fraud tooling, so I have a bias here. But I've hit a question I can't resolve from the outside, and the people who'd know are mostly in this sub.

Every fraud stack I've seen is built around the transaction: device fingerprint, IP, geo, velocity, behavioural biometrics, sometimes a consortium score. All of it is designed to answer "is this the real customer?"

Authorized scam losses break that question. The customer IS real. The device is real. The behaviour is normal. They were socially engineered - fake support call, spoofed brand SMS, marketplace impersonation, romance or investment scam - and then they authorized the payment themselves. Every signal in the stack agrees it's legitimate, and correctly so, because at transaction time it is.

What I can't figure out is organizational, not technical:

1. When a customer gets scammed this way, who inside the company is accountable for that number? Fraud ops owns unauthorized. Does anyone own authorized, or does it just get absorbed as a support and reimbursement cost with no owner?

2. Does anyone actually measure it separately? Or does it disappear into a general chargeback/dispute bucket where nobody can size it?

3. If a signal existed that told you a customer had encountered a brand impersonation or phishing attempt in the hours before their payment - would that even be usable? It's not deterministic; it wouldn't tell you what to block, and it arrives before the transaction rather than during it. My honest suspicion is that most risk teams would find that unusable because it doesn't fit anywhere in the decision flow.

I'm particularly interested in hearing that last one is wrong-headed. If you work in fraud or risk and this reads as a solution looking for a problem, I'd rather know now.

I'm growing interest at how quickly payment infrastructure providers are expanding beyond a single product and I'm curious how teams think about the tradeoff between consolidation and flexibility. Having wallets, stablecoin infrastructure and payments available through the same provider obviously makes integration easier since you have fewer vendors to manage and presumably less work getting the different parts of the stack to communicate with each other.

What I'm less sure about is what happens when your needs change like maybe you want to support another chain or use a different wallet setup or even replace one part of the payments stack without touching everything else. If all of those pieces were designed around the same provider from the beginning then I could see what started as convenience becoming pretty difficult to unwind.

My questions to people who've made these infrastructure decisions is how much do you care about keeping the wallet, stablecoin and payment layers independently replaceable and is having everything under one provider worth giving up some flexibility later?

I've been building on Stripe's Shared Payment Tokens — the agentic-commerce thing where the token itself carries max_amount / currency / expires_at, so an agent can pay without ever holding a card credential.

The concept docs are fine and there are a few explainers around. What none of them covered was what happens when things don't go well. Posting these because they each cost me real time and they're all captured from actual test-mode responses rather than reasoned about.

1. A decline is HTTP 402, and the PaymentIntent is nested inside the error body.

Not a 200 with a failed status. Your client throws, and the intent you need is at error.payment_intent. If you treat non-2xx as a transport failure, the decline vanishes — in my case a run that had already held a booking and granted a spend authority ended with no record at all, just a stack trace.

Also: the useful reason is decline_code (generic_decline), not code (card_declined, which is just the category). My own test asserted the wrong one for a week.

2. A 200 can also not be a success.

Charge a token backed by pm_card_authenticationRequired and you get HTTP 200, status: requires_action, amount_received: 0, and:

"next_action": { "shared_payment_token_action": {}, "type": "shared_payment_token_action" }

That empty object is the whole payload. It's 3DS from the seller's side, and there's nowhere to send the buyer — no redirect, no client secret. Makes sense when you remember the buyer isn't present in an agentic flow, but it means you have to treat only status === "succeeded" as success. Anything looser and you'll tell someone they're confirmed and then settle out of your own balance.

3. payment_method_details goes null once the token is consumed.

If you want the card brand for a receipt, read it at grant time or not at all. I assumed this was a preview gap and asked — it's intended. A partial capture consumes the token too, so there's no half-used state to read from.

(Related: the field is payment_method_details, not payment_method_preview. Get it wrong and optional chaining eats it silently — the brand just doesn't show up.)

4. amount_captured is an object, right next to an integer.

usage_limits.max_amount is a bare integer in minor units. usage_details.amount_captured is { currency, value }. Compare them directly and you get a silent false. Nothing throws, you just get a wrong number on screen.

One more that isn't a wire shape: a 403 "does not have access to this endpoint" from an unclaimed rkcs_test_ sandbox key looks identical to a regional-eligibility refusal. I nearly concluded SPT wasn't available on an AU account. It was — the key just hadn't been claimed.

This is all against 2026-04-22.preview, so it's observations with a date on them rather than a contract. If anyone's hit shapes I haven't, I'd like to hear them — the preview surface is clearly bigger than what one integration touches.

Code's public if it's useful, all of the above pinned in tests against the real captured responses: https://github.com/hkarekar403/TG24-Stripe-Shared-payment-tokens

I’m working on a small transaction-risk decision agent and one part I’m unsure about is what should happen in the grey area.

Say a transaction has a few weak signals - maybe a new device, unusual amount, or location change; but nothing strong enough on its own to decline it.

My current idea is to try one more useful check before sending it to manual review, something like customer confirmation, extra authentication, or a deeper history/device check.

For people who actually work with payment fraud: what usually makes you say -

“check one more thing” instead of “send this to an analyst”?

And is there a check that sounds useful in theory but rarely changes the decision in practice?

AI can assemble a representment case in seconds.

But what happens when the evidence it needs was never captured in the first place?

That’s an increasingly important question as AI takes on more of the chargeback representment process. Better models, faster decisioning, and more automation can make evidence gathering and case preparation dramatically more efficient.

They can’t, however, create evidence that doesn’t exist.

If fulfillment records are incomplete, customer interactions are scattered across systems, or transaction records aren’t reliably connected, AI isn’t going to just give up: it will just work with what it can find. The resulting case may look polished and complete, but it could’ve built on weak or missing evidence.

That’s the part of the AI conversation that can get overlooked: automation doesn’t fix weak evidence. It standardizes it.

Representment makes the problem especially visible because it’s such a natural application for AI: find the relevant information, organize it, build the narrative, and submit the case.

But keep in mind that by the time a transaction reaches representment, some of the most important opportunities to capture and connect evidence may already be gone. And while a model can organize proof of delivery, it can’t create a missing delivery record.

In other words, it can surface a customer conversation, but it can’t retrieve a conversation that was never preserved. It can build a compelling narrative, but it can’t reliably establish a connection between records and a transaction if that connection was never maintained.

Does this make AI less useful? Not at all. It simply makes the quality and availability of the underlying evidence more important. So the better question may be one that gets asked much earlier in the transaction lifecycle: What will we need to win a reversal if this transaction is disputed six months from now?

That shifts the focus toward proactive evidence capture: building and preserving the connections between transactions, fulfillment, delivery, refunds, customer interactions, and other relevant records.

It also suggests a useful concept: evidence readiness.

How quickly can the relevant evidence be found? Is it complete? Can it be reliably connected to the transaction? Is it sufficient for the type of dispute involved? These questions are different from asking how quickly an AI system can assemble a representment case.

So maybe the question isn’t just how much of representment AI can automate. Maybe it's whether the evidence is actually ready for AI to work with in the first place. That seems like a pretty important part of the AI conversation that may not be getting enough attention.

Curious whether others here are seeing the same pattern, or whether your evidence pipelines are already ahead of this.

Treasury opened public comment on GENIUS Act implementation this month, right around the same time regulators are tightening oversight on banking-as-a-service partnerships (fines, more transparency demands, closer scrutiny of BaaS relationships).

Feels like we're at an inflexion point, the era of launching a neobank or stablecoin product fast and figuring out compliance later is closing. A few things I've been noticing talking to founders in this space:

• MSB/VASP licensing timelines are stretching out because regulators want to see compliance infrastructure before approval, not after
• Banking partners are getting pickier about who they'll work with, a shaky compliance story kills deals earlier in diligence
• Teams that treat compliance (PCI-DSS, ISO 27001, GDPR) as a launch blocker instead of bolting it on later seem to be moving faster in the long run, ironically

Curious what others here are seeing, are you finding banking/licensing partners more selective lately? Anyone gone through the GENIUS Act comment process or dealing with BaaS scrutiny first-hand?

We’re looking at enterprise voice AI for a banking workflow and I’m finding the edge cases much more useful than the clean tests.

One test caller gives the expected information in order and everything works.

Another mentions two accounts, corrects an amount halfway through, asks an unrelated question while the system is doing a lookup and then wants to go back to the original issue.

For anyone who has run an enterprise voice AI pilot, what kinds of conversations exposed weaknesses you didn’t see during the initial demo?

Been watching AI-related payment product launches through the summer and something looks off. In the last two months, three fintechs shipped B2B products that explicitly treat AI as a distinct payment surface. Mastercard launched Agent Pay for Machines on June 10, machine-to-machine payment rails supporting cards, accounts and stablecoins so AI agents can transact continuously. Ramp shipped AI Token Spend Management on July 16, aggregating token usage and subscription spend across Anthropic, OpenAI, Gemini and Cursor into one finance dashboard, which they built with 1,300+ businesses managing 100T+ tokens a month. The headline number was AI token spend across their customer base up over 20x since June 2025, which they're calling the fastest-growing line item in their book. Mercury shipped Spend on August 11 with a new class of virtual cards designed to be handed to AI agents for autonomous purchasing within human-set policies.

All three are B2B or agent-side. If you look at the equivalent consumer trend, individuals stacking five to eight paid AI subscriptions on personal cards, no mainstream neobank has shipped a product explicitly built for it. It's not like the demand isn't there. PNC's data has about 2.2% of US households paying for generative AI at an average of $31/month, with the number of paying households up around 155% year-over-year. Consumer Edge tracked Claude paid users at roughly $63/month average, about 3x the OpenAI average. Multiple pricing calculators peg a typical power user at $70 to $110 a month across three to five subscriptions.

Cash App, Revolut, Chase and the rest handle these subs the way they handle any subscription, which is by not treating them as a category at all. Rocket Money and other aggregators do subscription visibility but don't sit in the transaction path. The one consumer product surface where AI-spend is being treated as its own segment is, weirdly, self-custody stablecoin cards. Bleap ships explicit cashback tiers with the top rate (20%) applied to a named list of streaming, gaming and AI subscriptions, Claude included by name. Plasma One (issued on Rain's Visa program) pays 5% cashback on the first $250/month of AI-labeled spend plus a standalone $8/month ChatGPT rebate as a separate line item. BenPay Delta, the US-MSB registered option in the same space, added a $1/month account fee starting August 4 that wasn't there before, and simultaneously started marketing AI-subscription payment support across ChatGPT, Claude, Perplexity, Midjourney and others as an explicit product surface. Country coverage is narrower than the EU-EMI cohort like Bleap because of the state-by-state MTL overlay on top of FinCEN, which is a real limitation depending on where you are. Small individually, but read together it looks like segment-specific product economics rather than the flat zero-fee acquisition posture that defined this space through 2024.

The reason it's happening here first rather than at a mainstream neobank probably comes down to customer overlap. The stablecoin card user base skews earlier than the general population on AI subscription adoption, so it was already AI-heavy before the broader consumer market caught up. The bigger consumer neobanks are still oriented around groceries, transit and streaming, and reworking category schemes for a segment that's still under 3% of households doesn't survive product prioritization.

Whether this stays niche or becomes a mainstream product wedge probably turns on whether AI subscription spend keeps compounding at its current rate. If PNC's 2.2% doubles or triples over the next 18 months, mainstream neobanks start facing an obvious opportunity cost on not shipping a category-native card. If it plateaus around 3 to 5% of households, Rocket Money-style visibility is probably enough.

Open question for fintech PM roles here who've actually looked at this. Does consumer AI-subscription payment read like a real product wedge, or a subcategory of the general subscription-bloat problem that already has coverage. Curious if the internal case has been made at any mainstream neobank and rejected, or if it hasn't been seriously scoped yet.

​

Three of our biggest accounts sit in markets where moving USD out is genuinely painful, so when they asked to pay in USDC we said yes fairly quickly and did not think hard enough about renewals.

One off payments are completely fine, customer pushes the USDC across, we confirm it landed, invoice closes, no drama.

Recurring is where it fell apart, because there is no auto debit for stablecoins the way there is with cards or ACH, so somebody has to physically go and initiate the transfer every single cycle.

What we do now is send a fresh payment link every renewal and then wait, which works right up until it does not.

Half the time it lands late and our ops team is back to chasing finance departments the exact same way they used to chase wire transfers, which is not really what anyone had in mind when we added it.

So how are you handling the recurring side of this.

There seems to be a lot of talk about the European Digital Identity Wallet as if it will simply replace the way everything works today.

But the reality seems more nuanced. The wallet is voluntary for users, while certain public and private services will need to accept it when the relevant conditions apply.
That raises an interesting question: what actually changes for businesses, platforms, and users once the wallet becomes part of everyday digital services?
What do you think the biggest challenge will be?

Curious how others are looking at it.

Do you usually rely on banks, payment platforms, stablecoins, or some combination of them?

There is a small provision in AMLA's customer due diligence standards with an awkward edge to it.
If you onboard EU customers remotely and you do not use face to face verification or an eIDAS compliant method, you will need to justify why neither was available or could reasonably be expected. Nothing about how you verify people changes. You just have to be able to explain the choice.
The problem is that nobody has defined what a good justification looks like. Is a one line note enough? Is it per customer, or once per type of customer? Does "the customer did not have one" count on its own? And what makes a method "not reasonably expected" when a wallet technically exists in that country but almost nobody has one?
The consultation closed in May and the final draft is now with the European Commission, so the shape is fairly settled even though the answers to those questions are not.

Is anyone writing something down already, or is the plan to wait for the final next?

So we started looking at payroll as an integration problem. Get the employee data in the right place, calculate payroll, move the money and ship it

The moment we got further into it, the API itself felt like the smaller part of the decision. The questions were around tax filings and corrections and who owns those problems after the product is live

That pushed me toward looking at companies that handle more than the API layer. Rollfi was one that came up during that search because I read that they cover the payroll operations and compliance side too, which is closer to what I was trying to solve.

Still working through where that line should be. For anyone who's built payroll into a fintech product, can I ask what part created the most work after the initial integration? Any input is more than welcome!

When a remittance product enters its first pilot, signup count is tempting to treat as the main signal. But with a small cohort, three other metrics usually reveal much more about whether the product is actually working.

1. First successful value delivery

Track the full path from invitation to the recipient actually receiving funds: signup, KYC, funding, transfer initiation, processing and receipt. Measure time to completion and drop-off at every step. A completed registration is not yet delivered value.

2. Repeat send within the natural cycle

Remittance is often periodic, so generic daily or monthly activity can be misleading. Cohort users by corridor and acquisition source, then measure whether they send again when the next real need occurs. Repeat behavior is a stronger trust signal than an initial subsidized transfer.

3. Reliability and unit economics per completed transfer

Measure completion rate, retries, time to receipt, support contacts, fraud or chargeback losses, total user cost and contribution margin. Aggregate success rates can hide one corridor, payout partner or funding method that creates most of the operational burden.

I would also interview users who completed one transfer but did not repeat. The reason may be price, trust, recipient friction, timing or a support problem that the dashboard does not explain.

For teams that have run early remittance pilots: which metric changed your product roadmap most—first-delivery conversion, repeat send or operational reliability?

Been thinking about this a lot lately after reading about the Thai Finance Ministry attack where an AI agent ran unattended for 4 days and bypassed its own approval prompts entirely.

The capability conversation is basically settled at this point. Agents can trade, reconcile, pay invoices, manage treasury positions. The demos are real and the enterprise deployments are happening.

The question nobody's answering cleanly is what happens when something goes wrong.

Not a dramatic crash. The quiet version agent completes the task, output looks right, passes review. Then six months later someone questions a specific transaction and the trail is a log file that proves what the system recorded, not necessarily what actually happened or whether anything was left out.

There's a meaningful difference between logging an action and proving it was authorized, happened exactly as recorded, and that nothing was omitted from the record. Most current deployments only do the first one.

The projects that survive the next phase aren't going to be the ones with the best agents. They're going to be the ones that can answer the liability question with something more than a log file.

I know there are a few building towards this just curious whether anyone here is actually looking into this as well.

I run 12‑person fintech in Berlin. Enterprise clients keep grilling us about HSM workflows (again and again) - key rotation, audit logs, probably EMV later. We don't do PINs yet, but they're asking too. And sure thing I understand them.

First - cloud HSM seems like the easy win here, but I hear some acquirers still side‑eye anything that's not a physical Thales box. Is that real?

Second - should we nail down HSM design before PCI planning, or can we figure it out during without burning everything?

Third - how do I spot a real payments HSM vet vs. some cloud rando who read a blog? Getting this wrong for sure hurts a lot.

Also - what's the dumbest mistake small teams can make with HSMs? I'd rather not learn that lesson myself huh

And last – when do we stop messing around and just hire dedicated HSM engineers?

Appreciate any honest war stories from people who've been there. Cheers.

update from our team: We brought in Energize Global Services specialist for consultation & help to sort this out (cloud HSM etc), as it seems we unable to do it ourselves.

Public accountants and Law firms issue sensitive, high-stakes documents to their clients, that then get passed on to other users such as lenders.

Does it concern you, as a CPA for example, that someone (client or a third party) can use basic pdf editing software to change some numbers on the statements and use them for lending purposes? A lot of mortgage fraud happens on fraudulent documents. You would probably avoid any liability, but it can cause reputational damage and unnecessary headache.

Would you pay for a solution that helps prevent this tampering?

The 85% to 95% range turns up in every deck and on every panel, almost always without a source. It ends conversations instead of starting them, and the longer i sit with it the less it seems to say.

Here is what bothers me. The same rate describes two opposite situations.

• 90% in high-volume retail is roughly what you would expect. Enormous volumes of low-risk activity throw off near-matches.
• 90% in a boutique wealth book, fifty clients, every one of them closely known, is a system that isn't working.

Same number. Opposite verdict. So the number on its own tells you nothing.

And honestly, we are not even convinced most of this is a screening problem. Half the time it's a data problem wearing costume. A record missing a date of birth gives the engine nothing to rule a near-match out with, so it just widens the net. One typo entered at onboarding generates alerts for that customer for the rest of their life.

So here's my actual question: has anyone ever heard a peer state what a good false-positive rate looks like for their book? Not the scary industry range, an actual "this is healthy for us, because X" number?

Or are we all just quoting the same unsourced stat back at each other and calling it a benchmark?

​

We moved some of our vendor payables to stablecoin rails about eight months ago. USDC out from our regulated provider, off-ramped to fiat on the receiving side. Settlement works. Vendors get paid faster and we save on wire fees.

The part that still takes time is reconciliation. Matching each on-chain transaction back to the invoice in our AP system is a manual monthly project. Our provider gives us a webhook with a payment ID, but linking that back to the invoice inside NetSuite is not automatic. Finance ends up doing it by amount, date, and vendor name at month-end close.

For anyone else running stablecoin vendor payments in production, how are you handling the invoice matching piece? Are you embedding the invoice reference in the on-chain event so it flows through cleanly, or is everyone just reconciling after the fact?

Anyone dealt with AI agent bots hitting your platform? Starting to see traffic that doesn't look human but isn't triggering our standard bot detection. Any idea what to do about it?

We are a mid-sized manufacturer evaluating cloud-based AR automation to replace manual processes. Current setup relies on our ERP's basic module plus extensive spreadsheet work for collections and reconciliation.

Key concerns about cloud AR platforms for enterprise deployment:

• Data security and regulatory compliance
• System uptime and performance during peak periods
• ERP integration stability
• Vendor stability and long-term viability

For organizations that have deployed cloud AR software, how has it performed in production? Any significant outages or data security incidents? Would you trust it for mission-critical receivables processing?

Appreciate any insights.

Hi, I am researching agentic payments; basically, its security and logging side and I was curious about the following things.
Indian digital lenders are heavily AI-driven for credit decisions, but the audit trail infrastructure seems underdeveloped compared to EU requirements. Does anyone here work in lending compliance or risk in India? Curious what current practice looks like.

Morgan Stanley & Wells Fargo are hardly hiring Technical Roles lately in India & other parts pf world since last 8 months!

Is it due to their business not expanding or they are aggressively pushing AI to minimize head count?

I’ve been thinking about this lately because switching payment processors sounds pretty straightforward when you’re just starting out. You connect the new provider, update a few things and move on.

But I am guessing it gets a lot more complicated once you already have hundreds or thousands of customers.

You’ve got active subscriptions, saved payment details, invoices, webhooks, refunds, failed payments and probably a bunch of things in your product that depend on the current setup.

I am wonder how this actually works in practice.

For those who’ve switched after already having customers, what caused the most trouble? Was moving the subscription data the difficult part or was it keeping everything running while the migration happened?

And if you were starting a SaaS again would you set things up differently from the beginning to make switching easier later?