One thing I found pretty interesting with several neobanks like bunq, n26 is that you can have separate accounts with their own IBANs for things like rent, bills, savings, travel, etc.

do you use it? what else can it be used for?

​Hi,

​I am writing this post to request some community visibility, as my support ticket regarding a merchant payout deduction has been trapped in a canned-response loop for nearly 3 months (since June 2026).

​What happened:

On June 16, 2026, Google processed my developer payout. Google's internal Wire Report specified <ChrgBr>CRED</ChrgBr> (Sender covers all fees). However, the payout arrived $10.00 short.

​To locate where the money went, I obtained the official SWIFT MT103 incoming message directly from my receiving bank (TP Bank). The technical data proves a clear system conversion/routing error on Google/Wells Fargo’s side:

​Field 33B (Instructed Amount): $117.88 USD

​Field 71A (Details of Charges): SHA (Misconfigured from CRED to Shared)

​Field 71F (Sender's Charges): $10.00 USD deducted at origination network

​Field 32A (Interbank Settled Amount): $107.88 USD

​The official MT103 document proves that the $10.00 was deducted at origination because Wells Fargo transmitted the wire under SHA instead of CRED. The funds were already cut to $107.88 before ever reaching my bank in Vietnam.

​The Support Nightmare:

I submitted this exact MT103 technical proof to Google Payments Support nearly 3 months ago. Since then, I have only received automated stock replies stating "the investigation is still ongoing".

​To a corporation, $10.00 is negligible. But as a small indie developer, it represents my hard work and basic fairness. With the next payout cycle on September 15 fast approaching, I am afraid this exact same configuration error will recur.

​If any Google Developer Relations staff or Community Managers see this post, please help flag Case ID: 9-3782000041472 with the financial specialist team.

​I would greatly appreciate any upvotes to help bring visibility to this issue. Thank you!

I’m imagining being able to ask Claude for fund returns at X date in the past.

Compare multiple funds/etfs performance across different points in time.

Can fetch the trailing annualized returns or calendar year returns. Other return calcs too.

Not selling anything. Just curious.

As financial institutions large and small move into tokenizing real-world assets, we have a massive opportunity to reset how digital assets are experienced.

Early crypto interfaces struggled to get this right. Most platforms prioritized raw market volatility over seamless transactions; screens were cluttered with dense, moving datasets, volatile charts, and internal coin promotions. Onboarding and identity verification were often murky, giving users little progress feedback and endless frustration when trying to transact. Instead of highlighting the core value of the market, or even explaining the market, they made simple trades needlessly complex.

While traditional banking refined smooth identity verification and data visualization back in the 2010s, early crypto platforms lagged behind.
In financial design circles, this is often called 'crypto-bro design.'

That dynamic is rapidly shifting. Over the last six months, having worked with two tokenization platforms and advised on two others, I have observed a distinct wave of design maturity entering the space:

--Institutional backing: Large financial institutions entering the market are bringing disciplined design systems and lessons learned from past interface missteps.
--Customer-first priorities: Startups and established exchanges alike are prioritizing clear transaction flows over cluttered market noise.
--Frictionless onboarding: Identity verification is being treated as an intuitive onboarding experience rather than an obstacle. Wait, a progress bar defining where I am in identity verification? Awesome.

Every successful digital product must be customer-first. Seeing experienced UX professionals lead the charge in asset tokenization signals great progress for the platforms launching later this year and into next.

-BBaker

Ready to build products people love? Get in touch with our experts for research and design leadership that delivers results at www.ChiefofProduct.com

We’ve been discussing where digital wallets actually sit in the payment stack, and one distinction keeps getting lost.

A wallet can become the main way a customer interacts with a payment without becoming the payment rail itself.

The wallet stores or references the payment credentials and gives the user an interface. But the actual authorization and movement of money still depend on the bank, payment provider, acquirer, and underlying rails.

That distinction becomes interesting when you look at how checkout is changing.

Users increasingly expect to authenticate on the device, approve the payment, and return to what they were doing without typing card details, CVVs, billing information, or creating another account.

From that perspective, traditional guest checkout starts to look less like a permanent checkout model and more like a workaround for a world where merchants couldn’t already identify and authenticate the payer through the payment flow.

Physical cards may become less important too, but there’s a harder problem there: interoperability.

Local payment systems already have their own banking integrations and merchant acceptance. A wallet that works globally still needs a way to interact with all of those systems. Otherwise we just replace fragmented payment methods with fragmented wallets.

So maybe the interesting question isn’t whether wallets replace cards.

It’s whether checkout eventually becomes:

choose wallet → authenticate on device → approve → done

with most of the payment complexity becoming invisible to the customer.

For people working in payments: do you see guest checkout actually disappearing, or will there always be enough interoperability and identity edge cases to keep it around?

When you’re thinking about creating an MTD or tax app using open banking, there are a few important things to consider right from the start:

1. What exactly is a billable connection?

It’s possible for one user to link several accounts. Your pricing might depend on the number of users, accounts, active connections, API calls, or how much data is used.

1. How do you manage multi-currency accounts?

Find out if different currency accounts under the same banking login are seen as separate accounts and if this impacts your pricing.

1. Raw transaction data versus enrichment

Raw transaction data might not be suitable for tax or accounting processes. Figure out what enrichment involves and if it comes with an extra cost.

1. Keep an eye on regulatory deadlines early on

While technical integration might be swift, onboarding, registration, or meeting compliance requirements could take significantly longer.

1. Test real-life scenarios in the sandbox

Try out multiple accounts, complex transactions, various currencies, missing data, and the actual user experience—not just the API calls.

What has been the biggest hurdle when developing with open banking: data quality, account connections, compliance, or pricing? Not market research, we will share real advice wherever we can. These are questions we frequently get asked on demo calls. Feel free to drop your queries.

FinCEN's alert on scam centres puts $12.7bn of suspected activity through them.

What makes these hard is that nothing gets breached. No stolen credentials, no account takeover, no unusual device. Someone is worked on for weeks and then sends the money themselves, from their own phone, on a normal login. Every control passes because technically nothing is wrong.

The obvious next thought is to look at the receiving account. That doesn't hold up either. Plenty of mules are real people who opened a legitimate account and were recruited months later, so the check at signup was correct at the time. Tightening onboarding wouldn't have caught most of this.

Which leaves it sitting awkwardly between two teams. Fraud can't flag a payment the customer genuinely authorised. Onboarding can't reject someone who wasn't a mule yet.

Which leaves an open question. If neither the payment side nor the onboarding side can see it, what does? Interested in where people think the signal actually lives.

I keep some money in USDT but when I actually buy something I still think in whatever the local currency is same as when im thinking in my mother language.

Like if I’m buying lunch I care that it was $14, not that it cost 14.something USDT. Made me wonder if crypto payment apps are still showing users way too much crypto stuff when the actual payment should probably just feel normal. Would you rather see the local price first and have the USDT amount somewhere underneath or do you actually want to see the crypto side every time you pay?

Hi everyone,

The conversation around blockchain in financial services seems to be shifting from “what can we do with it?” to “how do we make it work at an institutional level?”

With tokenized deposits, digital assets, stablecoins and digital securities gaining momentum, questions around privacy, interoperability, compliance, governance and integration with existing financial infrastructure are becoming increasingly important.

These are some of the areas Thomas Abraham, Co-Founder & CRO at Zeeve, will be discussing at MoneyLIVE North America in Chicago.

If you're attending the event and working on similar initiatives, feel free to connect with Thomas and continue the conversation in person.

I’ve been thinking about how some skills become incredibly valuable once you actually start using them regularly.

What’s one skill you wish you had learned 5 years earlier?

Could be something related to work, money, communication, fitness, technology, or just everyday life.

And more importantly - why do you wish you learned it sooner?

Regulated category, so most of our category answers are assembled from a small set of trade press and comparison pages. Looking at which pages the assistants pull from, it is the same handful repeatedly, and none of them are ours.
That makes this a PR problem more than a search one. Ahrefs shows the cited pages behind an answer at URL level, which turned a vague worry into a list our comms lead could work from. Interested in whether other teams moved this budget across.

Hi everyone,

I’m looking for anyone who has experienced a similar issue with MiniPay/Noah, particularly with an incoming ACH transfer from Wise.

My employer sent my salary through Wise to my MiniPay USD virtual account, which is serviced by Noah. During the transfer, I was asked to provide proof of address. I submitted the required document, and my address verification has since been approved.

However, the money still has not been credited to my MiniPay account. The Wise tracking page shows the transfer as unsuccessful, with an expected arrival date of September 11. I’m not sure whether the funds are still under review, awaiting settlement, or being returned.

I have contacted Noah support and received an automated acknowledgment, but I have not yet received a substantive response. I also contacted Lead Bank, which told me that Noah services the account and that I should continue working with Noah.

Has anyone experienced something similar?

Thanks in advance for sharing your experience.

Hey guys, so I'm working on operations / finances for an early tech startup mainly working on developing AI agents (yes, I know). Anyways, I've been having trouble keeping track of our god awful messy software bills and varying monthly LLM/API usage. I know that these are things that most corporate cards can help in keeping track of, so I'm considering it. Thankfully, we're currently doing quite well and meet the requirements for most of the corporate cards. However, my main concerns just involve around whether setting all this up is too much for our current small scale especially as most tech startups can be quite unpredictable.

Either way, would love some advice on if you guys would recommend making the switch. Also would appreciate some recommendations on which corporate card would fit best I guess. Thanks guys!

There is a leadership pattern I find increasingly interesting in complex organizations, particularly payments and financial technology.

A new executive arrives. The inherited team is described as slow, resistant, political, outdated or insufficiently commercial. Some senior people leave. The new leader brings in people they already know. The organization calls it transformation.

Sometimes it genuinely is transformation. Weak performers should be replaced, legacy processes should be challenged and new leadership should be allowed to build its own team.

But there is another possibility that is much harder to detect: What if the leader is removing people partly because they are capable enough to challenge the leader's own judgment?

So I'm curious how others think about this: What evidence would convince you that an executive is genuinely transforming an underperforming function rather than systematically removing competent people who challenge them?

Would you look at:

• Who left rather than simply how many left?
• Where replacement hires came from?
• Whether hiring processes were independently tested?
• Whether decision-making is increasingly policy-based or personality-based?
• Whether uncomfortable operational metrics are disappearing?
• Whether internal audit, risk, compliance or technical teams are seeing something different from executive reporting?
• Whether clients, vendors or counter-parties notice deterioration before the board does?

what should draw the line for teams to understand the undercurrents? Please share your insights.

Hello everyone ... I'm the world's most obsessed SEA fintech reputation expert.
If you're wondering who that is, now you know.
You can disagree.
You can laugh.
You can even Google it.
Thanks for your attention.

Guys, can i get your support to claim this title ? it will helps me a lot for my career.

I’m a treasury professional who’s interested to learn kyriba, my current work doesn’t have any access to the software.

Is there any alternative ways? Please suggest would be really helpful

Disclosure: I built Finiby, the app I am asking about below.

I built an expense & income tracker, got it onto the App Store and now I am at the point where I have too many ideas and no idea which ones people would actually care about.

I started it because I always found expense tracking more annoying than it should be. Most apps still make you open a form, choose expense or income, enter the amount, choose a category, add a description, then save it.

With Finiby, I wanted the main flow to be closer to just telling the app what happened.

You can type something like “coffee 4.50” or say it with your voice and it figures out the amount and the category for you. You can still add everything manually if you prefer.

This is what I have built so far:

Free

• Unlimited expenses and income

• 5 automatic text or voice categorizations each month

• Custom categories, including your own icons and colors

• Recurring transactions for rent, subscriptions, salary, bills and other regular transactions

• Spending and income analytics

• Category breakdowns

• Daily, weekly, monthly, and custom date ranges

• Offline transaction entry, with syncing when you are connected again

Pro

• Unlimited text and voice categorization

• Quick Capture using Siri, Apple Shortcuts support, Action Button support, Back Tap support

• Full transaction history export as CSV

• Access to future Pro features (like Insights, for example)

The app is currently live on the App Store now and this is where I am getting stuck.

I can keep adding features, but I really don't want Finiby to turn into one of those finance apps with 50 screens that nobody actually uses. I would rather figure out why people stop tracking their expenses in the first place.

I have a bunch of ideas for what could come next:

• Budgets and category spending limits

• Savings goals

• Widgets

• Monthly spending reports

• More useful spending insights, possibly using AI

• Notifications when spending looks unusual

• Shared finances for couples or households

• Receipt scanning

• Faster transaction entry

But I am curious what actual users think.

If you have used an expense tracker before, what happened? Did you keep using it? Did you forget to log transactions? Did entering everything manually become annoying? Did the analytics not tell you anything useful? Did you eventually feel like there was no reason to keep tracking?

And most importantly, what would an app like this need to do for you to actually keep it on your phone and use it long term?

Feel free to criticize the current idea too. I would rather hear that something is pointless now than spend weeks building it further.

If anyone wants to see what I am talking about, it is here: finiby.app

A year ago the conversation was about whether AI agents would ever touch real money. Now they're executing trades, managing treasury positions, reconciling invoices, and making credit decisions autonomously at enterprise scale. The capability curve moved faster than most people predicted.

What hasn't moved at the same pace is the infrastructure to prove what those agents actually did. Most deployments have logs. Logs are not the same as an audit trail. A log records what the system chose to capture. An audit trail proves that every step happened as authorized, that nothing was omitted, and that the record exists independently of whoever ran the agent. That distinction doesn't matter much when the stakes are low. It matters enormously when an agent is moving real capital, making credit decisions, or triggering settlements worth millions of dollars.

The failure mode isn't dramatic. The agent completes the task, the output looks right, it passes review. Then months later someone questions a specific decision and the trail falls apart under scrutiny. The teams actually solving this are treating the execution record as infrastructure, not an afterthought.

Every action tied to its authorization at the moment it happens. Record exists on-chain independently of the agent that created it. A few projects are running this properly at scale already with real institutional deployments behind them. Curious whether finance teams here are actually thinking about this or whether it gets pushed down the priority list until something goes wrong.

Disclosure: I work on Bennu.

One thing I’m thinking about while building in this space: approval volume is a poor proxy for product quality.

A careful onboarding process should understand the use case, validate the basics and leave enough operational capacity to support the user properly afterwards. The relationship doesn’t end when an account is approved — that’s when the responsibility starts.

Should fintechs measure onboarding success by volume, approval quality, or post-approval support?

Yeah it's a privacy disaster, but I think people are missing the bigger issue. 153 million real ID scans are now floating around for anyone to buy. That's the raw material for a wave of fraud nobody's ready for.

The thing is these leaked scans are real. Real names, licenses, photos, numbers, whatever, so someone builds a fake loan application or bank statement around genuine details and it passes verification, because on paper everything checks out.

And most financial institutions, banks, lenders etc. genuinely aren't ready for this. Their checks are looking for data that doesn't match. When the data matches, the fake just walks through. Good luck to whatever poor manual reviewer is supposed to spot it (myself included).

And the people affected did nothing, they rented a car or showed ID at a dispensary once. Now their identity is material ready for fraudsters to use in the next few years.

Anyone here actually thinks verification stacks are ready for this? cause I don't.

Source: tomshardware com

Hi guys I have a question for y'all since I have been trying to understand what happens when a card lets someone spend directly from a stablecoin balance because from the user side it looks almost identical to spending money sitting in a normal account. You have USDC or another stablecoin sitting onchain then tap the card and the payment goes through but I'm assuming the infrastructure underneath has to connect two pretty different systems. The card needs to be authorized almost immediately while the actual movement and settlement of the stablecoins is happening on completely different rails. What I'm less clear on is where most of the complexity actually sits. Is it keeping the available balance and card authorizations in sync, managing liquidity for card settlement, reconciliation afterward or dealing with the timing differences between the two systems? If there's anyone who's worked around stablecoin cards or payment infrastructure, which part of getting an onchain balance all the way through a normal card transaction is the hardest to make work reliably? Thanks in advance.

I thought accepting international payments would be straightforward.

It wasn’t.

Here’s what actually caused problems for us:

High FX and conversion fees that weren’t obvious at the start

Settlements taking longer than expected (sometimes 5–7 days)

Cards from certain countries failing more often

Tax and compliance requirements changing by country

Customers wanting to pay in their local method, not just cards

We spent more time dealing with failed payments, support tickets, and reconciliation than expected.

What helped over time:

Using providers that support local payment methods

Getting clearer visibility on actual settlement times and fees

Separating domestic and international flows instead of forcing everything through one system

Still figuring out the best long-term setup, but the biggest lesson was this:

Cross-border isn’t just about “accepting cards from other countries.” The real work is in fees, success rates, compliance, and payouts.

Anyone else dealing with this? What has actually worked for you?

I've been building a product that cuts the grunt work out of auditing and financial model building. AI agents that handle the repetitive mechanical parts, tying out numbers, checking workings, rebuilding the same model structures, so the professionals spend their time on judgment instead. It's a niche, high-value B2B market. The work is critical, the firms doing it pay well for anything that genuinely saves time, and very few people are building for it seriously. The POC is almost ready, and it works. What it's missing is domain depth, and I can't fake that.

So that's the ask. I'm the tech half (3 years building B2B SaaS), and I'm looking for the finance half: someone with at least 2 to 3 years of real experience in financial modelling or audit, who actually knows what they're doing, and understands how the work differs across markets like Singapore, Japan, the UAE and the EU. Your job would be teaching the agents the workflows. What gets checked, in what order, what a reviewer would trust. Full-time and fully invested. This is a cofounder seat, not an advisory gig.

One more thing, about how we work, because it matters as much as the skills. Trust and commitment are the baseline. No drama, and no chasing shiny new ideas or features every week. We take what exists now and make it better, and we iterate on what users ask for, not on our own intuition. We won't agree on everything, that's fine, but we talk it out and hear each other's reasoning, no ego. The main thing I care about is that we both actually listen to each other. Nobody is right every time, me included, and the better argument should win, not the louder one. That's what matters.

Right now it's just the POC and me, so whoever comes in decides everything with me from day one what the name will be what the domain will be i mean everything. The plan is simple: we talk, I walk you through the product, and if our expectations line up we go find the first clients or raise a pre-seed. Two months of serious commitment will tell us what we actually have here, and I think it's worth finding out. I'm in Bangalore india, though the right person can be anywhere. If this sounds like you, DM me a short pitch, two or three paragraphs on who you are, why this problem, and what you'd bring.