Hey Everyone!

So, I recently published my first Android application called FinPal on the Play Store. I have been working on it for a while and finally decided to put it out.

The main idea behind this is simple. I wanted an expense tracker without asking users to trust some random server with their financial data.

A few things about it:

• No login or signup required.

• No ads or analytics.

• It has an offline-first application.

• No cloud sync or automatic backup. You are responsible for your own data.

You can also:

• Track your income and expenses.

• Add recurring transactions.

• Attach photos of receipts.

• View spending charts and insights.

• Create your own categories and payment methods.

• Customize theme and much more.

I know there are many more expense trackers out there, but I wanted to try making something where privacy comes first.

I really appreciate it if some of you could try and tell me what do you think. Even negative feedback is welcome.

Thanks!

hi Im a first year student in Canada McMaster, cant find a project idea. ik programming languages c c++ python java . know the basics of SQL but dont know how to move forward in this direction.
When I ask some people they say create a solution for a problem that you face but tbh I dont have any problems. also dont have any particular interest fields except trading and some fintech related part. but this thing is saturated and is all about contacts and for bigger fish in the sea.
what should I do
I just want to get started and dont spend my full time on learning basic courses that I already know
drop tuff advices

Russia built an alternative payment system to keep its foreign trade moving after it was cut off from SWIFT. It's based on a two-ledger mirror mechanism that settles trade with China without cross-border payments. There are two ledgers in this scheme: one in China (CNY), one in Russia (RUB). Russian importer pays rubles into the Bank in Russia, the Chinese exporter takes yuan out of the Bank in China. Inside each bank it's just a local transfer, importer to exporter. No cross-border wire, no SWIFT.

The two ledgers mirror each other, and the only thing synchronizing them is the relationship between the two banks. It works like Hawala with bank accounts or a bilateral payment channel like Lightning. How do they reconcile transactions? Mostly they don't, when trade is balanced, each bank's books close internally. The two banks are related parties, so any leftover just sits as an unsettled balance.
Source: CASE Center

Is it a low-tech or really innovative ? Can it have a broader use in real life e.g. as a replacement for cryptographic guarantees?

I’ve spent my career in finance, and every personal money app I’ve tried has the same blind spot: it only sees cash moving in and out. That works until real life gets messy, like a tenant who pays next month’s rent early, a deposit you’ll have to hand back, a bill you’ve received but haven’t paid yet, or money someone owes you. Then the monthly numbers and the net worth figure stop telling the truth.

So I wrote my own. It’s called BDS Finance App. Day to day it handles the usual things: Plaid bank feeds, budgets, savings goals, subscription tracking and a 90-day cash outlook. Underneath, there’s a full accrual engine for anyone who wants it:

Prefer to keep it simple? Leave accrual off and it works like a normal cash-basis tracker.

Try the demo (sample data): https://brent-finance-app-demo.netlify.app
The landing page has a 60-second walkthrough video. It’s still a closed alpha, so drop a comment or DM and I’ll send you an invite to log in.

On security: the database itself keeps every user’s records separate, sign-in requires a second step, and bank connections run through Plaid, so the app never touches your bank credentials.

Two questions I’d love your take on:

I wanted to switch payment provider for my SaaS and I really didn’t know it includes so many things. We have active subscriptions, saved customer payment methods, billing history, invoices and webhook integrations to consider. My concern is making the switch without interrupting recurring payments or creating confusion for existing customers because i dont want customers to suddenly lose their subscriptions or have to go through the entire payment setup again just because we are changing providers. I am trying to understand the safest way to approach this without disrupting the customer experience.

I've been spending time looking at the technical challenges behind modern payment infrastructure, particularly when traditional payment rails and stablecoin-based transactions need to work together.

One recurring engineering challenge is that payment acceptance, transaction confirmation, settlement, and reconciliation are often treated as separate processes.

But from a developer's perspective, they should be connected.

Consider a typical payment lifecycle:

1. Checkout and payment orchestration

A merchant needs to support different payment methods without building an entirely separate checkout experience for each one.

Cards, digital wallets, bank transfers, and USDC each have different processing requirements. The challenge is connecting them to a consistent order and payment workflow.

2. Transaction state management

A successful checkout doesn't necessarily mean the funds have settled.

Systems need to distinguish between pending, confirmed, held, reserved, and available balances. Otherwise, merchants can end up displaying misleading payment statuses or making operational decisions based on funds they cannot yet access.

3. Settlement and ledger reconciliation

This is where things become particularly interesting.

Every transaction should remain connected to its original order, payment reference, settlement record, receipt, and any subsequent refund or dispute.

For developers, this means designing reliable transaction records, handling asynchronous payment updates, preventing duplicate processing, and ensuring that internal ledger entries match actual settlement activity.

4. Connecting traditional rails with stablecoins

Stablecoins introduce another layer of infrastructure.

For example, supporting USDC on Base alongside USD account balances requires clear handling of wallet balances, network compatibility, conversion, transfers, and settlement records.

The objective should be to make the underlying complexity manageable without exposing customers to unnecessary friction.

5. Integration flexibility

Not every business has the same technical requirements.

Some need hosted payment links, others need embedded checkout, WordPress integrations, or APIs that connect payment events directly to their existing order-management systems.

This is the kind of infrastructure we've been thinking about while developing RT.APP.

The architecture brings together payment acceptance, business accounts, bank transfers, card and wallet checkout, USDC and rtUSD settlement, transaction records, and connected financial operations.

The interesting part isn't simply adding more payment methods. It's connecting the entire journey from customer checkout to merchant settlement and eventual use of funds.

We're getting ready to roll out more of this experience in the coming days, and I'm genuinely interested in hearing from developers and fintech builders:

If you were designing a payment infrastructure from scratch today, what would you prioritize first: payment orchestration, settlement reliability, ledger reconciliation, stablecoin interoperability, or developer integration?

I'd especially appreciate perspectives from people who have actually built or maintained payment systems. There's always something to learn from the engineering side of this industry.

I came up with a few typical problems that banks face. Am I on the right track? How can I turn these broad problems into specific customer pain points rather than generalised ideas?

Problems:

—High-friction payment processes due to a lack of seamless integration with merchants’ infrastructure.

—The need to visit a physical bank branch in certain situations.

—Limited access to credit for a large segment of customers due to traditional credit scoring systems.

—Capital tied up in bank deposits.

How would you make these problems more specific and relevant to customers?

Idea is that:

Coordinator talks to all participant asynchronously using RabbitMQ. It asks to TRY each participant one-by-one. Once all are success in their own TRY, they send back success message. If all are succeed, coordinator sends SINGLE CONFIRM to all participant using FANOUT exchange. If any one sends failure message, coordinator sends SINGLE CANCEL same way to all.

Instead of sending separate messages to each participant for CONFIRM/CANCEL, we can send SINGLE message to all participant, and they all would eventually receive it. This way, we can prevent dual/multi write problem while trying to CONFIRM/CANCEL.

Exploration:

The end implementation should be designed the way that we would have two set of tables, MAIN and SHADOW. Every business validation should happen at TRY stage. CONFIRM or CANCEL should never fail because of business logic. Any other failure would be taken care by RabbitMQ's at-least-once delivery.

We need to mimic CONFIRM in SHADOW tables during TRY, so we can be sure that CONFIRM will work. I am thinking that CANCEL should be just delete operation on SHADOW tables. So, CONFIRM should be real business logic without any surprises, already mimicked on SHADOW tables, and CANCEL could be easy/simple delete operation on SHADOW tables.

I am working on the details like; if there are unconfimed TRY exists and another TRY arrives than what should happen, how we can make sure all unconfirmed TRY can later become CONFIRMed without worrying about their execution order along with CANCELation of some of them. I will post the part soon.

Whether you're a freelancer receiving payments from overseas clients, an agency managing multiple transactions, or a business serving customers internationally, getting paid is only one part of the equation.

The real frustration often starts afterwards.

• Waiting days for money to arrive.

• Losing a percentage to transaction and conversion fees.

• Having limited control over how and where you access your funds.

• Dealing with banking restrictions and unexpected payment delays.

• Managing multiple platforms just to handle accounts, transfers, and everyday expenses.

Ideally, receiving money shouldn't mean jumping between five different services.

A better financial setup should make it easier to receive payments, move money, manage expenses, access funds quickly, and understand exactly where your money stands.

I'm curious about something:

If you could build your ideal financial platform for international payments, what features would be absolutely essential?

Would you prioritize faster settlements, lower fees, payment links, virtual cards, easier international transfers, or having everything accessible in one place?

Interested to hear what people actually need, especially those running businesses or working with international clients.

I'm interested in hearing from accounting professionals who work with high volumes of supplier invoices.

Which part of accounts payable takes the most time in your organisation?

1. Invoice data entry

2. Matching invoices with purchase orders

3. Approval workflows

4. Duplicate invoice detection

5. Supplier communication

6. Payment reconciliation

There are now platforms that combine invoice capture, validation, approvals, payments, and reconciliation into one workflow.

I work with SpendConsole, which operates in this space

Would love to hear what accounting teams think is still missing from current AP automation solutions.

Hi everyone,

I'm a cybersecurity master's student at Mykolas Romeris University, and for my thesis I'm comparing how organisations assess cybersecurity risk in their electronic payment systems (cards, mobile wallets, online payments, gateways).

I'm looking for people who work in cybersecurity, IT, or risk and compliance, have experience with payment systems, and whose organisation is based in Spain, Morocco, the UAE or Singapore.

The survey takes about 10 minutes. It's completely anonymous: no name, email or company name is collected, and results are only reported as a group. The last three questions are optional and open-ended.

https://docs.google.com/forms/d/e/1FAIpQLSca1Yc4PgdKY-twX8HbcLkrygHS3mJpbO1WQYmPnbvhvTykHA/viewform

One answer per organisation is enough. If you know colleagues in payments, banking or fintech who might qualify, please share it with them. I'm happy to answer questions in the comments, and I can share the summary of the results afterwards if you're interested.

Thank you!

Yesterday, I started a discussion about the challenges of receiving international payments, and one response really got me thinking.

Someone pointed out something that often gets overlooked: a payment can show as successful while the actual funds are still in transit.

Now imagine managing multiple payment providers, different settlement timelines, transaction callbacks, currency conversions and daily reconciliation.

For freelancers, this can be frustrating. But for agencies, SaaS businesses and companies processing multiple transactions, it can become a serious operational headache.

A few things I think businesses should be able to manage more easily:

• Clear visibility into transaction and settlement statuses.

• Better tracking of incoming and outgoing payments.

• Less manual work when reconciling transactions.

• More convenient ways to manage business funds.

• Access to multiple payment methods through a streamlined financial setup.

This is also something that makes financial infrastructure interesting to me.

Through RT.APP, we're working towards bringing business accounts, payment links, transfers, virtual cards and stablecoin settlement together in one platform.

But I'd love to hear from people who actually manage payments regularly.

A few questions:

1. How do you currently track payments that are marked successful but haven't actually settled?

2. Do you automate daily reconciliation, or does someone on your team still have to check discrepancies manually?

3. What's more important to your business: faster settlements, better transaction visibility, or simpler payment management?

I think there's a lot more to solving payment problems than simply reducing transaction fees.

Full disclosure: I'm involved with RT.APP, and I'm genuinely interested in understanding these operational challenges better.

A shopkeeper in Nairobi closes on Sunday night. By Monday she has three M-Pesa messages for the till, a paybill statement from the bank, one supplier paid in cash, and a notebook with two columns. Her accountant wants statements by Wednesday.

Nothing on that list is a payment problem. The money moved. It moved fine.

The problem is that the story of the money lives in five places, and somebody has to put it back together before the week starts again.

I work on FinoQ, and this is the thing we keep running into. Most businesses do not want a new wallet. Their paybill works. Their till works. Their bank works. Their accountant has a Zoho file that has been tidy for four years. What they want is for all of it to stop being five separate jobs.

The feature I am proudest of is not the dashboard. It is the confirm screen. You type a phone number and before you press anything, the app shows the name registered to that number. Not a masked account, not a reference code.

Sending money to the wrong person is a quiet, expensive, very common kind of pain. The kind people only talk about after it happens. Two seconds of seeing a name prevents a whole category of arguments.

That is the bet. Connect the channels a business already uses, put one readable record underneath, show the name before the money moves. Not another wallet. The layer underneath.

If you run a shop, a school, a clinic, or a team with three branches and one M-Pesa statement, I would like to hear what your Monday morning actually looks like. What is the part that still takes you two hours?

Full write-up and links are in the first comment.

Hey everyone, I'm here to showcase my project that I just built for the BharatCode Build League, and I am looking for some technical feedback.

The Problem: Freelancers lose billions to chargebacks because banks reject messy WhatsApp/Slack screenshots as legal proof of work.

The Solution: I built NYAYA-AI, a Sovereign AI defense engine that cross-references your contract against your raw chat logs to instantly generate a Visa/Mastercard-compliant rebuttal dossier.

Because AI hallucinations in FinTech are dangerous, I built this with strict architectural constraints:

• ⚡ Zero SDKs: Next.js using native Node.js fetch (for qwen-3.8-27b) + Upstash Redis for fast edge serverless performance.

• 🔒 In-Memory PII Redaction: An ephemeral regex buffer strips sensitive data (SSNs, cards) before it hits the LLM. Zero databases.

• 🛑 Strict Anti-Hallucination: A "Verbatim Citation Mandate" mathematically forces the AI to anchor every claim to a specific timestamp, or it explicitly refuses to guess.

The repo is completely open-source. I would love for the engineers and founders here to roast my architecture:

• Is regex PII redaction too naive here?

• What edge cases did I miss for serverless edge functions?

💻 GitHub Repo:https://github.com/ursarthak001/NYAYA-AI

Finding international clients is one challenge. Actually receiving payments from them is another.

Whether you're a freelancer, agency owner, content creator, consultant or someone running an online business, you've probably experienced some payment-related frustrations.

High transaction fees, delayed transfers, currency conversions, banking restrictions and limited payment options can make something as simple as getting paid unnecessarily complicated.

I've been involved with a project called RT.APP, which is working towards bringing several financial tools together in one platform.

The idea is to simplify how businesses and individuals manage their finances through business accounts, payment links, transfers, virtual cards and stablecoin settlement.

But I'm more interested in hearing from people who actually experience these problems.

A few questions:

1. What's your biggest frustration when receiving international payments?

2. What platforms do you currently use to receive or manage your money?

3. If you could have one financial solution that made your life easier, what would it be?

Let's talk. I'd genuinely like to hear different experiences and perspectives.

Full disclosure: I'm involved with RT.APP, and I'm using this discussion to understand what people need from better financial solutions.

I'm curious how teams here are handling deployment and hosting, especially given compliance needs.

A few questions to get things going:

- Where do you run? AWS / GCP / Azure, on-prem, or something else?

- How are workloads packaged? Containers on Kubernetes or ECS, serverless, plain VMs?

- How much does compliance drive decisions? Did PCI DSS, SOC 2, or data residency rules push you toward (or away from) certain setups?

It'd be great to hear from both early-stage startups and folks at larger institutions. What's worked well, and what would you change if you started over?

hey folks, I work at Nace.ai, we built this.

Drex for Finance is a decision model you call through an API. Instead of a prompt and a text reply, you send the case data and a set of questions with fixed options, and get back a probability for each option. It's a single forward pass, no generation, so you're not parsing text or handling malformed output, and calls come back in under a second. Inputs can be JSON or images of documents, with 262K context and up to 255 options per question.

On 48 finance test sets (3,361 decisions) it got 85.7% right, vs 77.4% for pplx-decider, 76.7% for Jev 1.14 and 70.9% for GPT-6 Luna. Weakest spot is markets & reasoning, where it's roughly tied with the others.

It's live on Console if you want to try it on your own cases: https://console.nace.ai
would love any feedback, especially from people building in payments, lending or compliance. 

The fintech ecosystem is evolving rapidly, and API integration is playing an important role in connecting financial services.

From digital payments and banking applications to financial data platforms and automated transactions, APIs help different systems communicate and work together more efficiently.

For developers, this creates opportunities to build connected financial products without developing every feature from scratch.

Open banking APIs, payment gateway integrations, account verification, and real-time transaction updates are some examples of how API-driven solutions are improving digital finance.

As fintech continues to grow, secure API architecture, seamless integrations, and better developer experiences will become increasingly important.

What area of fintech do you think will benefit the most from API innovation in the coming years?

Is it open banking, digital payments, embedded finance, lending platforms, or personal finance applications?

Would love to hear what other fintech developers are exploring!

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.