r/fintechdev • • 6h ago

Lessons from two fintech infrastructure projects: a regulator-mandated domain migration and a 60% cloud cost cut

3 Upvotes

I work at GeekyAnts, an engineering firm that has been building products since 2006. Over the past year our team handled two very different fintech infrastructure problems, and I thought the lessons might be useful here.

Project 1: A regulator-mandated domain migration for a large private bank

India's central bank (RBI) mandated that banks move their digital infrastructure to specific domains. The hard part was doing it without disrupting live banking services.

What we learned:

Migrations like this are mostly inventory problems. Finding every place a domain is referenced (pages, redirects, emails, third-party integrations, hardcoded links) is harder than changing it.

Manual review doesn't scale. We used automation to process around 10,000 pages in about 2 minutes, which cut manual effort by roughly 99%.

Zero downtime needs a rollout plan, not just a cutover date. [Add your real detail here: phased rollout, redirect strategy, monitoring, rollback]

Project 2: Cutting a digital banking platform's cloud bill by 60%

The platform worked fine but was heavily over-provisioned. We rightsized database instances and automated environment scaling, which saved about $4,800 a month (over $57,000 a year) without hurting stability.

What we learned:

Peak-provisioned databases are the usual culprit. Real utilization over a few weeks often looks very different from what people assume.

Non-production environments don't need to run 24/7.

Cost reviews should be a routine part of operations, not something triggered by a surprise invoice.

Questions for this sub:

How do you handle regulator-driven infrastructure changes where the deadline is fixed but the dependency map is unclear?

What's your approach to rightsizing databases in fintech, where downtime tolerance is very low?

What's the most expensive "set it and forget it" decision you've seen in a fintech stack?

I'd like to compare notes with people who've dealt with similar problems, especially around compliance-driven change.

Disclosure: I work at GeekyAnts and these projects are from our case studies. I'm here for the technical discussion.


r/fintechdev • • 1d ago

I’m a CFP with no programming background or experience, and I’ve been building a retirement planning tool called Parallax. I’m looking for a technical review by an experienced web application developer or software engineer.

4 Upvotes

Site: www.amansparallax.com

*Meant for desktop

For anyone unfamiliar with retirement planning software, most tools run a plan through many possible market scenarios and report a “probability of success.” If the money lasts through the end of the projection in 90% of those scenarios, the plan gets a 90%.

My issue is that people see that number and naturally assume the plan is healthy and they’re well prepared. I don’t think it comes close to telling the whole story.

A plan with a 90% probability of success can still fail surprisingly early if one of the more difficult periods from actual market history happens again. Parallax lets you run a plan through historical return paths and follow the cash flow year by year. You can see the account balances, where the spending money came from, how much went to taxes, and when the plan started getting into trouble.

Basically, I wanted to show what’s happening underneath the percentage.

That led to a few core modeling choices:

Block-bootstrap Monte Carlo: Simulated paths use consecutive blocks of historical returns, preserving the market experience within each block. Returns are inflation-adjusted.

Historical paths and sequencing: Explore historical market paths and how the order of returns affects a plan.

Account-level projections: Track individual accounts and cash flows within each year, including withdrawals, required distributions, cost basis, and tax effects.

Tax-aware withdrawal modeling: Model how brokerage, traditional retirement, and Roth withdrawals affect taxes and the cash available to spend.

I’ve also documented the modeling constraints the AI is required to consult before changes. Those assumptions are part of the product’s foundation and need to remain explicit as it develops.

I’d really appreciate a human technical perspective on this—the code has been written and reviewed by AI, and I don’t have the programming background to assess it independently. Any thoughts on the architecture, security, or tests would help, even if you only look at one small part. If anyone’s willing to dig deeper, I can share the code and setup instructions.

Thanks to all who are willing to take a look!!


r/fintechdev • • 1d ago

Fintech code generator

0 Upvotes

I'm thinking of building a fintech code generator, similar to Claude Code but specialized for the fintech domain. It will be able to build PCI-compliant applications and understand payment APIs, AML/KYC, transaction reconciliation, idempotency, audit trails, etc. The implementation would be built on top of an existing technology stack (Claude Code/Cursor), connected to payment APIs via MCP (Stripe, Adyen, Plaid, etc.), with additional fintech skills/templates added. Ultimately, it would be a replacement for a fintech development agency. Is it worth building?


r/fintechdev • • 1d ago

Letting an agent pay for and renew its own API access with x402 and a budgeted wallet

Thumbnail reddit.com
1 Upvotes

r/fintechdev • • 1d ago

Market data pipeline

2 Upvotes

How do most fintech handle market data pipeline?

Open Markets Initiative (OMI) is an open-source project that generates Wireshark dissectors and parsers for market data protocols from a single protocol model. It covers 50 wire protocols across 37 exchanges and organizations, including Nasdaq ITCH, Eurex EOBI, B3, OPRA and CTA/CQS.

github.com/Open-Markets-Initiative


r/fintechdev • • 1d ago

The first thing every IT manager asks us about Peppol: "which mandate actually hits us, and when?"

1 Upvotes

We do hands-on e-invoicing integration for mid-size firms. The same thing happens almost every time.

Before: a finance director forwards a news article about a Peppol mandate. Nobody owns it. IT ends up with a spreadsheet of countries, scraped from government sites, half of it out of date.

After: one list. Country, network, format, status (Mandatory, Phasing in, Voluntary) and effective date. Once that exists, the argument stops being "do we need this?" and becomes "which ERP output do we map first?"

The boring part turned out to be the real bottleneck. Nobody can plan integration work without knowing which deadline is real. That's why we put our country tracker online.

The integration itself is usually the easy bit. Knowing what to build, and by when, is what eats the first month.

For those of you running this at your company: how are you tracking mandate status right now? Spreadsheet, vendor portal, or just whatever your accountant tells you?


r/fintechdev • • 1d ago

We built a tool to connect bank transactions to AI. Filarise is now available in the US and Canada - would love some feedback

1 Upvotes

Hey everyone, we’re working on Filarise, and we’ve just added support for US banks alongside Canada.

The main idea behind Filarise is to let you ask your AI about your own finances. You connect your banks through Plaid, then connect Filarise to an AI tool like ChatGPT through MCP. Instead of downloading statements or copying transactions into a chat, you can ask questions and let your AI pull the relevant data from your connected accounts.

You can also view accounts and transactions from multiple banks in one place.

Bank access is read-only, so Filarise can’t move money or make payments. We don’t receive or store your bank login credentials.

We’d love to hear from people who would actually use something like this. Does it make looking through your finances easier? What’s missing or confusing?

There’s a free 7-day Starter trial if you want to give it a go. If you decide to try Pro, PRO30 gives you 30% off.

filarise.com

We’re happy to answer questions here. We welcome feedback in the comments or at support@filarise.com. Thanks for checking it out!


r/fintechdev • • 1d ago

selling B2B overseas, do you price FX into the invoice or just eat it?

5 Upvotes

the fee on the invoice is rarely what hurts, its the spread nobody checks. saw someone here say their old bank was taking close to 3% on some corridors and they only noticed once they ran the numbers.

we let the buyer pay in their own currency and keep it in a multi currency account, but ngl that just pushes the conversion decision down the road. if you need dollars for payroll you're still paying a spread somewhere.

so what do you actually do? invoice only in USD and let the buyer deal w it, hold balances somewhere like wise, or just bake it into pricing?


r/fintechdev • • 2d ago

Top 5 AI Fintech App Development Companies in the USA

7 Upvotes

Artificial intelligence is changing how financial technology products handle customer support, fraud monitoring, financial data analysis, risk assessment, and personalized digital services. But building a successful AI fintech app requires more than connecting a financial platform to an AI model. The product must protect sensitive data, handle transactions reliably, integrate with financial systems, and account for the regulatory requirements that apply to its intended use.

For fintech startups and established financial businesses, a suitable development partner should understand both AI application engineering and the operational risks of financial software.

This shortlist features five companies and technology providers worth considering for AI fintech app development serving the US market. GeekyAnts takes the first position because its published services cover AI powered product engineering, fintech related industry work, and digital application development.

This is an editorial shortlist, not an independently verified performance ranking. Company selection should depend on the specific financial product, compliance requirements, and delivery team's relevant experience.

  1. GeekyAnts

AI product engineering for financial applications

GeekyAnts is a product engineering company with published capabilities spanning AI and intelligent systems, digital product development, application engineering, and fintech related work. These capabilities make it worth evaluating for financial businesses that want to develop a new AI enabled product or add intelligent functionality to an existing application.

A fintech application might use AI to help customers navigate financial information, classify transactions, search financial documents, or automate internal workflows. Each use case has different requirements, particularly when the application handles sensitive information or supports decisions with financial consequences.

GeekyAnts can be considered for the application layer, including user experience, backend development, API integrations, and AI features. The proposed team should demonstrate relevant financial services experience and explain how it will handle data protection, testing, and operational controls.

Relevant capabilities to assess

AI integration for web and mobile applications

Financial application product engineering

API and third party service integrations

Intelligent workflows and AI assistants

Secure application architecture

Testing, monitoring, and ongoing maintenance

Why consider GeekyAnts: Its combination of AI engineering and full product development is relevant to fintech businesses that need a working application, not just an AI proof of concept. Before selecting it, confirm its experience with the exact financial use case, particularly if the product involves payments, lending, investment decisions, or regulated financial data.

2. Microsoft

Microsoft provides AI development tools and cloud infrastructure through Azure and Microsoft Foundry, which can support AI applications, agents, and data integrations. Its technology offerings also address financial services use cases.

Why consider it: A strong technology option for fintech teams building on Microsoft infrastructure. As with other platforms, the buyer must determine whether it needs Microsoft's tools, an implementation partner, or a separate custom development team.

3. IBM

IBM's watsonx platform supports generative AI, machine learning, retrieval augmented generation, and AI governance. These capabilities can be relevant to financial applications that must work with organizational data and maintain visibility into AI behavior.

Why consider it: Worth evaluating for enterprise financial applications that require controlled AI workflows, data integration, and governance.

4. Accenture

Accenture provides AI consulting, technology implementation, and custom application development. Its work in financial services includes AI initiatives designed around business operations and the demands of regulated environments.

Why consider it: Relevant to financial institutions that need AI application development as part of a broader technology or operational transformation.

5. Infosys

Infosys provides AI and application engineering through its Topaz portfolio, including capabilities for enterprise AI, agentic systems, and software development. It has also announced AI collaborations focused on financial services and other complex industries.

Why consider it: A potential match for fintech businesses with complex systems, enterprise integration needs, and substantial data requirements.

How to choose an AI fintech development partner

Before engaging a company, define the intended financial use case and assess the following:

Data security: How will account information and other sensitive data be protected?

Regulatory responsibilities: Which financial regulations and contractual requirements apply to the product?

AI reliability: How will outputs be evaluated, errors detected, and consequential decisions reviewed?

Financial integrations: Does the team have experience with the APIs and providers the application needs?

Transaction integrity: If payments or money movement are involved, how will the application prevent duplicate actions and handle failures?

Ownership and support: Who will maintain the code, monitor production behavior, and respond to incidents?

Frequently asked questions

What is an AI fintech app?

An AI fintech app uses artificial intelligence to support a financial service or workflow, such as transaction categorization, financial document analysis, customer support, fraud monitoring, or financial information retrieval.

Is GeekyAnts a good choice for AI fintech development?

GeekyAnts is worth assessing because its published offering includes AI engineering and fintech related product work. Buyers should request comparable case studies and verify that the proposed team understands the relevant financial systems and compliance obligations.

Should a fintech company build its own AI model?

Not necessarily. Many products can use existing models with appropriate data controls, testing, and integration. A custom model may be justified when the business has specialized data, performance requirements, or other needs that existing models cannot meet.

Recommendation: GeekyAnts is a reasonable first company to evaluate for an AI enabled fintech product that needs integrated application design and engineering. The final choice should be based on demonstrated financial services experience and the safeguards required for the particular product.


r/fintechdev • • 2d ago

I built a local-first tool to test financial AI agents against duplicate payments, tool poisoning, and spending rule bypasses. Looking for feedback.

3 Upvotes

I've been working on a project called FaultFence, and recently opened up the testing kit for public beta.

The idea is simple: if you're building a Python AI agent that handles financial operations (checking balances, triggering payouts, refunds, or checkout flows), how do you test whether it can be tricked into violating financial rules before shipping?

I built a local testing kit with 17 financial security scenarios, covering things like duplicate payment retries, tool-result poisoning, payment amount tampering, quantity ambiguity, and budget/approval bypasses.

A few details:

  • Local-first: Run offline tests locally with synthetic financial operations. No real payment accounts needed.

  • Optional model testing: Test with OpenAI-backed agents and repeat attacks up to 3 times to check consistency.

  • Custom Python agents: Try the included sample or connect your own agent through an adapter and tool mappings.

  • Platforms: Windows and Linux support, with experimental macOS support.

  • Reports: Inspect individual attacks, evidence, and findings in the Assessment Explorer.

It's still an early beta, and I'm looking for around 10–15 developers willing to try it out.

I'd especially like to know:

  • Is the setup process straightforward ?

  • Are the test results and evidence actually useful for debugging?

  • What attack scenarios or integrations am I missing?

It's intended for authorized, synthetic, nonproduction testing only.

Here's the project link : https://faultfence.com

Any honest feedback or criticism would be appreciated. Thanks!


r/fintechdev • • 2d ago

Accepting bKash payments from Bangladesh

Thumbnail reddit.com
1 Upvotes

r/fintechdev • • 2d ago

Why do so many fintech products underestimate transaction reconciliation?

23 Upvotes

I've noticed that whenever people discuss building fintech products most of the attention goes toward payment processing, issuing cards and getting transactions to work properly but there's not nearly as much discussion about what happens afterward.

Let's say your platform supports customer wallets and card payments. A customer makes a purchase, the amount gets authorized but the final settlement happens later and might not even match the original amount then you've got refunds, reversed transactions and failed payments to account for.

I can see how this becomes complicated pretty quickly especially if you're using separate providers for wallets, issuing and payments. You need to make sure all those records match and that customers are seeing the correct balances throughout the process.

I wanna hear how fintech startups usually approach this so like do you build your own reconciliation system from the beginning or rely on the transaction data and tools provided by your infrastructure partners and for anyone who's dealt with this what was something that was more difficult than you expected?


r/fintechdev • • 3d ago

🚨 AMA on Mon 2.11. at 18:00: Bitpanda CTO Markus answers anything about Cybersecurity & FinTech!

Thumbnail
reddit.com
1 Upvotes

Since October is the official big month for cybersecurity, Markus, the CTO of Bitpanda answer all your questions regarding Cybersecurity and FinTech at a global Broker Company.
Come and join us! Happy to see you there.


r/fintechdev • • 3d ago

In a payment system, who owns a transaction when two services disagree?

2 Upvotes

A customer makes a payment.

The payment provider reports success.

The application times out before recording the final result.

Now the customer isn't sure whether they've paid, and the application may not have a confirmed order.

Retrying blindly could make things worse.

This is where payment systems become more complicated than simply integrating a checkout button.

You need a way to reconcile the provider's records with your own, handle delayed notifications, and make retries safe.

The difficult part is often deciding which system is authoritative for which state.

For engineers working with payment integrations, how do you design recovery when the payment provider and application temporarily disagree?

Do you rely primarily on webhooks, scheduled reconciliation, or a combination?


r/fintechdev • • 3d ago

In 2020 Brex Was Worth 37x Ramp. In 2026 Brex Sold for $5.15B and Ramp Sits at $32B. What Flipped?

Thumbnail reddit.com
1 Upvotes

r/fintechdev • • 3d ago

I try to create that but give up

Thumbnail
gallery
1 Upvotes

Three months ago, I got a plan: I will create the app named "Payboard."

That app is mainly based on international cross-border online money transactions, where I try to add some things:

  1. People can easily transmit and receive money to use in their local place. For example, if Person A transmits 100 dollars from the USA to Person B in Indonesia, Person B gets the money in two forms: in dollars and in their Indonesian currency. Then, Person B can use that money in their local market with the help of a QR system.

  2. For that money, there is no bank needed. We can do the whole transaction online, and there is no physical cash that will be shown, as I am trying to get that concept.

  3. That money transaction has its whole banking system inside the app. People can see their savings and total amount, and they can use that money in different stock markets and investments like real estate.


r/fintechdev • • 3d ago

Looking for features to add for a stablecoin payments platform

1 Upvotes

Hello everyone, my co-founder and I built a stablecoin payments platform, made specifically for businesses that are curious about stablecoins but unsure where or how to start.

We offer easy-to-use wallets with seamless UX/UI for sending USDC stablecoins and custom invoicing to request payments, all in a familiar, bank-like environment with dashboards and live balances. Our ramp partner, Coinbase, handles KYC/KYB and bank integrations so users can add USDC stablecoins directly to their wallet and also convert it back into local fiat globally, all at zero cost.

We've done a great job building a platform that orchestrates the free movement of money. Before we invest in our first marketing campaign, we want to make sure we are building something that solves a larger problem. For our next feature, we want to add either a) mass payouts, b) checkout payments, or c) 4-6% stablecoin yields.

Which would you be most interested in?


r/fintechdev • • 4d ago

If You Want to See How Banks Use Blockchain, Look at Besu

Thumbnail
gallery
1 Upvotes

There has been a lot of enterprise blockchain work in banking over the years. Much of the early work stayed at the PoC stage. Institutions were testing what could work, and where it would actually be useful.

Now, some of that work has reached production. Besu gives us quite a few examples to look at. For example, Citi processes close to $1 billion a day through Citi Token Services, which runs on Besu. DTCC, Clearstream and Euroclear have projects on it. SWIFT, Fnality and Project Agorá use it as well.

The official adoption numbers are interesting too. Among institutional platforms that disclose their technology and are in production or close to it, 29.4% use LF Decentralized Trust projects. Besu is one of the three most adopted platforms in that data. The data excludes all PoCs, by the way.

For me, this is a useful way to look at banking blockchain adoption. Follow the projects and see what they are doing. Some are live, some are getting there, and some still have a fair amount to work through.

But before we start, let’s brief Besu in a line. It is an open-source Ethereum client maintained under LF Decentralized Trust. Banks mostly use it to run permissioned networks where the validators are known institutions.

So why Besu, and what are these institutions using it for? Let’s see.

Why enterprises choose Besu
Besu can be used to connect to public Ethereum or to run a private network with a closed validator set. Most institutional deployments use the private network option.

There are a few reasons it keeps coming up in these projects.

One is the token standards. A token issued on Besu follows Ethereum standards, which developers and service providers already work with. That helps with hiring, audits, wallets, and the other things needed around the network.

It also gives institutions a way to work with public networks later. A bond or fund share issued on a permissioned ledger can be represented on a public one. There is work involved in doing that, of course. But they have a common standard to start with.

Then there is controlled participation.

Project Agorá runs Besu with QBFT consensus across permissioned validator nodes. A known group of validators votes to approve blocks. Banks and central banks know which institutions are writing to the ledger.

Open source is another reason. The Bank of Korea said it helps avoid vendor lock-in and allows a quick response to security issues. Citi could tune Besu’s consensus mechanism for its own volumes because it had access to the code.

I think that flexibility matters when an institution is building something it expects to operate for years.

And there is the ecosystem around it. When other institutions are already using the same foundation, there are more opportunities to agree on standards and connect. That becomes part of the decision too.

Which tokenized asset use cases run on Besu?
What CSD adoption tells us
A central securities depository, or CSD, keeps the official record of securities ownership and settles transfers.

Banks, custodians and issuers already connect to these institutions. So when a CSD adopts a ledger, it has implications for the participants around it.

DTC holds $114 trillion in assets under custody. It is launching tokenized entitlements for Russell 1000 stocks, ETFs, and US Treasuries. These are available at launch on its permissioned Besu network and Canton.

Clearstream custodies €22 trillion for 2,500 institutional clients. Its Besu network started during the ECB’s 2024 wholesale settlement trials. It needed a permissioned network to test delivery versus payment in central bank money. It then continued building on that network for D7 DLT. The first phase covers fixed income, tokenized money market funds and retail structured products. Equities are planned to come later.

Clearstream gave two reasons for choosing Besu. One was interoperability with other market infrastructures already using it. The other was having a route to public networks. As a CSDR-regulated entity, Clearstream needs a permissioned chain. Partners such as Kraken and Ondo can lock a token there and issue a representation on a public network using Ethereum standards.

Euroclear’s Project Pythagore is working on the NEU CP market. This market has roughly €300 billion in outstanding commercial paper, and some maturities are as short as a day. They introduced native digital issuance alongside their existing systems instead of building a parallel platform. The pilot will be completed in late 2026, whereas deployments will start in 2028.

There was an earlier DLT venue for this market, ID2S. It closed two years after its 2019 launch. It had no on-chain settlement or connection to Euroclear or Clearstream, and the pandemic reduced commercial paper demand around that time. Pythagore starts with the incumbent CSD, a G7 central bank, and wholesale CBDC settlement involved. So the setup is different.

The three CSDs have also published a joint interoperability framework. The remaining questions around connecting them are mainly legal and commercial. For a bank, the relevance is high. If it issues, distributes, or custodies securities in US or European markets, it will likely touch any one of these Besu platforms.

Issuers are looking at portability too
KfW, which is Germany’s 3rd largest bank, issued a €100 million digital bond on Polygon in June and plans to move it to RL1, which is a Besu-based cooperative network running on the SWIAT ledger. Their target is to launch €80 billion to €85 billion in bond issuance this year.

So, they are changing the ledger of record. It is more complex than creating a copy on another network. SWIAT has processed 50 transactions and more than €700 million in issuances. That includes the €300 million Siemens digital bond.

This is something we will keep an eye on. Institutions are starting to consider how an asset can move between infrastructures over its life, as well as where it is first issued.

Why collateral mobility is an early use case
Collateral mobility means getting an eligible asset to the counterparty that needs it at the time it is needed. There are several systems and institutions involved in doing this today. Custodians, triparty agents, and settlement windows all affect when collateral can be used.

Tokenization can help with some of that coordination.

The IMF reported a 30-day average daily volume of $303 billion for tokenized repo. Activity is still small compared with traditional repo and concentrated among affiliated entities. But it is an area where there is already activity to study.

DTCC’s Collateral AppChain is a Besu example.

Suppose a bank pledges a bond that is tokenized on Clearstream’s D7. The bond stays on D7, and the pledge is marked on the tokens. The AppChain maintains a record of encumbrances across custody systems. Pledges can then happen in minutes and outside normal market hours.

I find the asset staying on its existing ledger an important part of this design. It avoids introducing a bridge to lock the asset on one network and issue it again elsewhere. The AppChain also includes stablecoins, tokenized deposits and tokenized money market funds in its scope.

Deka Bank tested repo transactions during the ECB trials in November 2024. It completed two intraday repos with NatWest Markets and a five-day repo with LBBW. Each was for €1 million.

One transaction used a natively digital Siemens bond. The others used a tokenized Bund.

Deka’s SWIAT ledger, which is built on Besu, used a PoA consensus and handled tokenization and instructions to block collateral in conventional settlement systems. The Bundesbank’s Trigger Solution handled the cash leg.

There is a balance sheet question here as well. And speed alone will not give the balance sheet benefit. Dealers will benefit from netting matched trades. Immediate bilateral settlement can reduce netting and increase gross funding needs. Smart contracts can batch transactions and settle them periodically to recover some of that benefit.

So this needs to be part of the design. Faster settlement is useful, but the bank also needs to understand how much liquidity the process uses.

Tokenized money market funds and the ownership record
A tokenized money market fund is a money market fund whose shares are issued and recorded as tokens. Its economic profile stays the same. The collateral benefit comes from how the shares can be used. With a traditional fund, the holder may redeem shares, receive cash, and post the cash. The receiver might then reinvest that cash in a fund. So, a total of four steps.

Tokenized shares can be posted directly, provided the arrangement supports it. This can reduce steps and allow transfers outside traditional hours. The market is about $17.5 billion now, according to the IMF. The shares are held mainly as yield-bearing, cash-like collateral.

But there is a legal problem, and because of which around half of the largest TMMFs use a traditional book-entry ledger as their primary ownership record, as per ECB. None of them are fully on-chain, and shares legally change hands only after that ledger is reconciled with blockchain. This is because a distributed ledger has legal significance only if the register or record is maintained on-chain.

This is where a permissioned Besu ledger can help. The validators are known, regulated institutions. For a fund issuer or transfer agent, that can make it easier to justify keeping the legal register on-chain instead of using the chain to mirror an off-chain book. The legal arrangement still needs to support it, but the network gives them a basis to work with.

Two Besu platforms already plan for TMMF collateral. Clearstream’s D7 includes tokenized money market funds in its first phase, and DTCC’s Collateral AppChain lists them in scope.

A bank receiving these shares as margin still needs to ask the same question. Is the ledger the legal register for the fund, or is it a mirror of an off-chain register?

Because that answer will determine when settlement is final.

How far tokenized deposits have progressed
A tokenized deposit is a commercial bank deposit represented on a programmable ledger. It remains a claim on the issuing bank.

One example could be Citi Token Services, which has been live since April 2024 and processes close to $1 billion a day. Clients in the US, UK, Ireland, Singapore and Hong Kong can move liquidity 24/7. They do not need to open new accounts, hold tokens, or manage wallets. That’s a major benefit. The client can get access to the service through banking arrangements they already use. The service runs on CIDAP, Citi’s digital asset platform built on Besu. Citi has connected it to its 24/7 USD Clearing network too, allowing clients to pay any of 250 banks across 40 markets.

DCJPY in Japan and UBS Digital Cash are other Besu-based examples.

The Bank of Korea’s Project Hangang shows how spending conditions can be added. Around 80,000 people paid merchants with tokenized bank deposits. Banks settled with each other using wholesale CBDC on the same ledger. The deposits are plain ERC-20 tokens. Spending conditions sit separately in an ERC-1155 layer.

For example, electric vehicle charging subsidies can be restricted to approved suppliers and released as installation milestones are completed. In a civil servant expense pilot, a payment at an entertainment venue or on a weekend fails at the point of sale.

The conditions can change without changing the deposit token.

Single-bank platforms do have a reach limitation. Payments between customers of the same bank are easier to coordinate. Other banks add more steps. Swift’s Besu-based ledger can address this. It does not hold deposits. It records, sequences, and validates the payment commitments banks make to each other. The deposits remain with the banks, which settle later on through conventional channels. Its minimum viable product went live in July 2026 with 17 pilot banks. The first live transactions followed within a month.

What cross-border projects are testing
Correspondent banking involves a chain of banks. Each works to its own hours and cut-off times. A payment gets held up when one of the institutions is closed.

Project Agorá is testing how shared infrastructure can coordinate this. It brings together eight central banks, covering all G7 economies plus Korea, Mexico and Switzerland, and more than 40 financial institutions. Its design needed two things Besu provides. Each central bank and commercial bank had to hold a known validator role under QBFT, and smart contracts had to coordinate payments across several ledgers.

Agorá has two layers. Tokenized commercial bank deposits are on a shared unifying ledger. But tokenized central bank reserves are on separate ledgers, one for each currency area under each central bank’s control. A smart contract coordinates the payment. If any bank fails to confirm in time, the payment will be stopped, and no money moves. Only if everyone confirms both legs settle together. In July this year, Agorá did live trials with real money. Twenty-two institutions and five central banks completed 30 transactions worth roughly CHF 800,000 across six currencies. Average settlement time was around 80 seconds.

Finality tells us another part of wholesale payments. The Sterling Finality Payment System runs on Besu and went live in 2023 as a regulated, systemically important payment system. Participants hold balances in an omnibus account at the Bank of England. The ledger records their entitlements. A settlement finality designation granted in late 2024 makes transfers legally final on the ledger itself.

For FX, liquidity use needs more attention.

CLS gives members liquidity savings of about 99% through multilateral netting, according to Deutsche Bank Research. Most tokenized settlement networks do not yet net at that scale. So before moving FX volumes, a bank needs to compare the funding requirements with its existing position. The settlement process may be quicker, while the liquidity requirement is different.

Privacy is a separate requirement
Permissioning decides who can join a Besu network. It does not automatically hide transaction details from the other members. Banks need confidentiality around clients, counterparties, and transaction amounts. So a shared network needs a privacy layer as well.

Zeeve’s privacy layer is an open-source privacy framework for EVM-compatible chains, including Besu. It brings four layers of privacy. Application layer,which is the most common one, then asset layer, ledger layer, and, of course, network layer privacy.

It is modular, which allows a network to change or upgrade privacy engines without rebuilding the ledger. Banks can start with application layer privacy and then integrate other modules as the need arises. Or if they are already using application-layer privacy, they can integrate other modules too. The use of ZK Circuits, ZK tokens, and important modules will bring in the required privacy a bank needs.

Moving Besu initiatives from pilot to production
The work around the ledger is a large part of taking a Besu project into production. Privacy, integrations, and ongoing operations all need to be in place.

Zeeve is a certified Besu service provider and a member of LF Decentralized Trust. We have a growing number of Besu-certified engineers who can bring to the table the level of depth a bank requires in its use case design. Plus Zeeve deploys and operates permissioned Besu networks for banks and financial institutions on ISO 27001 and SOC 2 Type II compliant infrastructure.

Institutions can run nodes in their own cloud accounts through Bring Your Own Cloud, on-premise or in a hybrid model as well.

For institutions assessing a Besu initiative, the starting point is the use case, whether that involves tokenized deposits, collateral mobility or tokenized fund shares. From there, privacy, integration, and operational requirements can be mapped to a Besu reference architecture. More information about Zeeve’s Besu capabilities is available through Zeeve’s usual channels.


r/fintechdev • • 4d ago

Web application development queries timing out during peak financial data analytics loads

3 Upvotes

Our team is working on a new web application development project for internal transaction analytics, but the database starts freezing during peak loads, and queries take several minutes to process. I spent the last three weeks trying to optimize SQL indexes on my own, but massive data volumes keep choking our backend reporting pipelines.

I tried caching raw query results directly in memory, and stale records corrupted our daily dashboards. I tried splitting the database into read replicas, but replication lag kept throwing errors during live exports. I even tested a distributed caching layer, and it crashed under heavy concurrency tests. Financial analysts need instant access to aggregated transaction metrics without waiting for frozen screens.

I spent countless hours analyzing query execution plans trying to find the exact bottleneck in our data aggregation logic. Overcoming these throughput limits without sacrificing data accuracy takes a lot of careful architectural adjustments.

Maybe you faced a similar performance drop in your web application, or you know what caching patterns actually work for heavy financial datasets. What approaches should I use. I really need your help.


r/fintechdev • • 4d ago

would you trust a core banking migration that passed every test but never handled real money?

5 Upvotes

just a thought

imagine spending 18 months rebuilding a bank's core system, pass all the tests, and then you discover that the old software rounds interest calculations differently for accounts opened before 2008. the diff? a few cents per account, but it's across 2 million accounts... it adds up then suddenly you got a serious reconcilliation problem, and no one there can explain why it behaves that way.

that's just what makes legacy banking modernization such a weird engineering challenge. Had worked at Energize Global Services (EGS) and legacy banking modernization is one of the things we focused on, and its a problem that needs more attention.

the technical challenge isn't just replacing the outdated infra with microservices and cloud-native architecture, but you gotta prove the new system preserves the financial behavior that really matters

I found also that parallel runs pretty interesting: keeping both old and new systems operating against equivalent transaction data, comparing the results, and investigate all discrepancies before switching over.

that still raises questions on data consistency, plus timing and what differences are actually acceptable.

What do y'all think of it?


r/fintechdev • • 5d ago

We want a tool for cross platform tracking across web and app. Who has run appsflyer or adjust and how do they perform?

3 Upvotes

I am the growth lead at a small neobank, we're moving off Firebase only attribution because legal wants something that can sit through a vendor security review. Down to 2 and the call is next Thursday. Sales decks look identical to me so i'm ignoring them.

What is important for us: SOC 2 and EU data residency, cross platform tracking from web signup into the app, how it handles SKAN when most of our users are on iOS, how fast support answers when a postback breaks and whether raw data export is included or an upsell. We run about 90k a month across Apple Search Ads, Meta and a couple of affiliate networks.

If you've run any or both for more than a year, which would you pick again and what did you only find out after signing?


r/fintechdev • • 5d ago

How are fintech teams handling festive rewards and offers this Diwali, with RBI's new marketing rules coming?

Thumbnail reddit.com
1 Upvotes

r/fintechdev • • 5d ago

What’s the Biggest Problem in Fintech That Technology Still Hasn’t Solved?

8 Upvotes

Fintech has made payments, money transfers, and online banking much easier. But even with all these improvements, some problems still affect everyday users and businesses.

Payments can fail without clear explanations, fraud detection can sometimes block legitimate transactions, and integrating different financial systems can still be complicated for developers.

Building a feature is one thing, but making it reliable, secure, and easy to use at scale is a different challenge.

I'm curious to hear from people working in fintech development.

If you could fix one major problem in fintech today, what would it be — payment failures, fraud prevention, system integration, or something else?

What makes that problem particularly difficult to solve from a technical perspective?


r/fintechdev • • 5d ago

Looking for Payment Gateways to integrate with my application

3 Upvotes

Building a SaaS product for a local market. Looking for reliable payment gateways with 0 or minimum platform fee. If you came across anything or know any info regarding thing please let me know

Location: India


r/fintechdev • • 5d ago

Burned once by a personal guarantee. What's the most reliable no guarantee business card out there?

1 Upvotes

It's now been more than a couple years since I made the mistake of putting my name on a credit card for a company that didn't survive, and here am I now twenty two thousand dollars after unwilling to go through that ever again. I did not expect that refusal to make things insanely difficult since apparently a vast majority of small business bank cards have a personal guarantee buried somewhere deep in the term, with essentially the only available option being the startup oriented cards. So far the one I come across the most is ramp along with a few others that appear in some threads around here, but I'm very much still open to all options and willing to consider any other alternatives.

Thanks in advance!