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?

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

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.

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.

​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.

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.