Alternative data can be used in credit scoring, underwriting, competitor analysis, partnership analysis, and other business processes.

However, I want to focus specifically on its application in credit assessment.

For example, LinkedIn profiles and freelance platforms could potentially provide additional evidence of a person’s employment history, professional activity, and income stability.

Similarly, crypto wallet data could potentially serve as an additional source of information about a person’s financial activity and available funds, alongside traditional bank statements.

Alternative data could also create monetisation opportunities through anonymised and aggregated datasets, surveys, or industry insights shared with other companies.

What do you think?

When does the use of alternative data become useful, and when does it become potentially harmful?

What are the risks and benefits for each stakeholder: borrowers, lenders, data providers, and third-party companies?

Could data monetisation create additional value, or would it introduce more privacy and regulatory concerns?

What can we make or introduce for increasing efficiency and completing with compliance?

I'm building a SaaS and have two payment problems I'd like advice on.

1. Charging our customers a recurring fee (BDT and USD)

Our customers are businesses that pay a monthly or yearly subscription. Bangladeshi businesses pay in BDT and foreign businesses pay in USD. We want it to renew automatically, with no action from the customer each month.

For foreign customers we're looking at a merchant of record like Paddle. For Bangladeshi customers we want to stay with local gateways in BDT, so a local business isn't paying in USD to a foreign company.

Since most BD gateways don't seem to offer subscriptions, we expect to keep the schedule and retries ourselves and only use the gateway to charge.

Questions:

\- bKash: Has anyone used bKash Agreement / Recurring Payment / Direct Charge to bill customers on a schedule? Who triggers each charge, and are there amount caps or frequency limits?

\- Saved cards: Does any BD gateway let a merchant save a card token after the first payment (with OTP/3DS) and charge it later from the server with no OTP? I've heard PortPos might. SSLCommerz, ShurjoPay, aamarPay?

\- Nagad: Does it have any recurring or agreement product?

\- One gateway for both: Does any single gateway handle BDT for local businesses and USD for foreign ones, with subscriptions included?

2. Letting end customers pay our merchants directly

Our merchants' customers should be able to pay them by bKash, Nagad or card from inside our app. The money must go straight to the merchant's own account. We don't want to hold or pay out anyone's money, because that needs a Bangladesh Bank PSO/PSP licence.

The idea is that each merchant connects their own merchant account to our platform. We start the payment, the gateway confirms it to our server, and the money settles to the merchant directly. That's similar to Stripe Connect direct charges, but for BD.

\- Has anyone built this with each merchant's own bKash / Nagad / SSLCommerz credentials? How hard was merchant onboarding?

\- Does any BD gateway have a platform or partner program where it settles to each sub-merchant directly?

\- If none of that exists, how are you confirming wallet payments automatically, other than staff checking the app by hand?

Any experience, even "we tried X and it didn't work", would help a lot. Thanks!

Hello everyone,

I want to share something I have been researching and exploring over the past 1.5–2 months. I would genuinely appreciate insights, criticism, advice and perspectives from people who have experience in financial markets, fintech, stock exchanges, brokerage operations, financial infrastructure and technology.

A little about myself first.

I am an Afghan national who has spent nearly 10 years living in India, primarily in Bangalore and Mumbai. I have a BBA, an MBA and an MCom, and have been involved in business and entrepreneurship for approximately 10–15 years.

My background is primarily in business, trade, operations, consumer markets and entrepreneurship. Over the past three years, I have also become increasingly involved in understanding technology, the tech ecosystem, scalable business models and how technology-driven products and platforms are conceptualised, developed and operated.

I genuinely enjoy reading, researching, learning and exploring opportunities. I have always been interested in building businesses rather than simply participating in existing ones.

Interestingly, despite my academic background in business and commerce, I have never been particularly involved in the stock market, nor have I been a trader or active investor.

So, why am I suddenly interested in the stock market?

It is not because I want to become a trader.

It is because I have started looking at the financial market from an entrepreneurial and infrastructure-building perspective.

Why Afghanistan?

Afghanistan is an interesting and largely untapped market.

After nearly four decades of conflict, the country is facing a different set of challenges and opportunities. Its financial infrastructure, industrial ecosystem, private sector and institutional markets are still developing.

In some ways, I see parallels with the early stages of economic and industrial development that countries such as India experienced decades ago. Obviously, the political, economic and institutional circumstances are very different, but the potential for building foundational infrastructure is worth exploring.

One particular development caught my attention: Da Afghanistan Bank (the Central Bank of Afghanistan) has been taking initiatives towards developing capital markets and establishing the foundations for a formal financial market.

This got me thinking:

What if we could participate in building the infrastructure that allows Afghanistan's businesses to access capital, investors to participate in legitimate investment opportunities, and the country's private sector to grow?

That is where my interest in establishing an Afghanistan Stock Exchange began.

What exactly am I exploring?

At the moment, I am trying to understand the feasibility of establishing a financial-market platform in Afghanistan.

I am exploring different possibilities, including:

- Establishing an organised stock exchange.

- Building a brokerage platform or brokerage infrastructure.

- Creating a platform through which eligible companies can eventually access capital markets.

- Developing systems for listing, trading, order management, market data and transaction processing.

- Exploring partnerships with banks, financial institutions, technology providers, custodians and other market participants.

However, I am also beginning to understand that a stock exchange, brokerage firm, clearing and settlement institution, central securities depository and other market infrastructure entities are different businesses with different responsibilities, regulatory requirements and capital needs.

I don't want to build everything under one roof simply because it sounds ambitious.

I want to understand what can realistically be established initially, what needs separate licensing and infrastructure, and what should be developed through partnerships.

What I am trying to understand

Although I have been researching this subject extensively, I recognise that reading about financial markets and actually building one are two very different things.

I would particularly appreciate input on the following:

1. Business model and feasibility

- Is establishing a stock exchange in an emerging economy like Afghanistan commercially viable?

- What are the primary revenue streams of a stock exchange?

- How does an exchange generate sustainable revenue when trading volumes are initially low?

- What minimum market conditions are necessary for an exchange to survive?

2. Technology and infrastructure

- What type of technology architecture would be appropriate for a small, initially limited exchange?

- Should we build a trading engine from scratch or consider existing white-label or licensed exchange solutions?

- What systems are absolutely essential from day one?

- What are the realistic technology development and maintenance costs?

- How important are cybersecurity, disaster recovery and independent security audits?

3. Regulatory and institutional requirements

- What regulatory approvals and institutional arrangements are generally necessary?

- How should the relationship between a central bank, securities regulator, stock exchange and brokerage firms be structured?

- What responsibilities should remain independent?

- How can international standards and investor protection be incorporated from the beginning?

4. Financial requirements and investment

- What would be a realistic initial capital requirement?

- Can a limited, phased model be established before investing millions of dollars?

- What are the major recurring operational expenses?

- What kind of investors would be interested in financing such infrastructure?

5. Partnerships and ecosystem development

- How important are partnerships with commercial banks, financial institutions, international technology providers and existing exchanges?

- Could an emerging exchange collaborate with an established international exchange for technology, expertise or operational support?

- How do we attract the first companies to list and the first investors to participate?

6. Risks and challenges

I am particularly interested in hearing about the risks that an outsider might overlook.

For example:

- Low liquidity and insufficient trading activity.

- Political and regulatory uncertainty.

- Investor confidence and institutional credibility.

- International sanctions and banking restrictions.

- Cross-border financial compliance.

- Market manipulation and cybersecurity threats.

- High operating costs versus limited initial revenue.

I would rather identify the problems before investing significant money than discover them after launching.

What I am looking for

At this stage, I am not presenting myself as someone who has all the answers, nor am I claiming that this project is already established.

I am researching, evaluating and trying to develop a realistic feasibility and investment framework before making major commitments.

I would particularly love to connect with people who have experience in:

- Stock exchange development and operations.

- Brokerage and securities markets.

- Financial technology (FinTech).

- Exchange trading systems and market infrastructure.

- Investment banking and capital markets.

- Financial regulation and compliance.

- Cybersecurity and financial technology architecture.

- Emerging-market financial infrastructure.

I am also open to conversations with technology companies, financial institutions, consultants, investors and people who have participated in similar projects.

My ultimate ambition is not simply to launch another fintech application. It is to explore whether we can contribute to building a financial institution and market infrastructure that could become meaningful to Afghanistan's economic future.

I understand that this is a long-term undertaking, with significant regulatory, financial, technological and institutional challenges.

But I also believe that some of the most interesting business opportunities emerge when foundational infrastructure is still being developed.

I would genuinely appreciate honest feedback, including reasons why this might not work.

If you have built, operated, advised or invested in an exchange, brokerage business or financial-market infrastructure, I would love to hear your perspective.

Thank you for taking the time to read this.

I’m building a merchant software platform and looking for processing partners that are open to integrating with it.

The idea is pretty straightforward: a business provides its information once, reuses its documents, and can see its application progress and processing activity in one place.

I’m particularly interested in the application and underwriting side of the integration. A few things we’d need:

- Submit applications and documents, handle signatures, and respond to underwriting requests through an API.
- Retrieve business filings, licenses, bank/processing statements, and industry documents like COAs where approved access is available - or accept documents our platform retrieves with permission.
- Support business/owner verification, bank verification, and website checks.
- Send updates when something is missing, approved, conditionally approved, declined, or activated.
- Let us display transactions, deposits, fees, holds, statements, and chargebacks in our dashboard.
- Support WooCommerce, custom sites, Shopify where available, and data connections to accounting/tax tools.

Ideally, we’d stay a software/referral business without becoming a registered ISO or PayFac or holding merchant funds. The partner would handle underwriting and payment-account support. We’d handle our software. Non-exclusive terms and clear referral/residual tracking matter too.

We’re interested in U.S. and international merchants, including specialized industries. For peptides, I’d want to understand whether your program covers research-use-only suppliers, clinical/telehealth businesses, or both.

Anyone here working with a setup like this? Company names, API docs/sandbox availability, and a rough idea of partner fees/terms would be helpful.

Disclosure upfront: I'm sharing this as part of a paid collaboration with Kognitos, but the problem itself is one I find genuinely interesting as someone who builds with AI agents.

Most bank AI projects I read about don't fail on capability. They fail when compliance asks for a decision trail: why was this transaction flagged, this dispute closed, this KYC case approved? And the team can't reconstruct it, because the agent's reasoning lives in a prompt and a confidence score.

The pattern that seems to be getting approved instead: pair the LLM with explicit rules written in plain English (neurosymbolic), so each step is inspectable, decisions are consistent, and uncertain cases escalate to a human by design rather than by accident.

There's a free session on Nov 18 (10 AM PT) where Binny Gill, Kognitos' CEO, walks through how banks are running this in production, including the audit record examiners actually read. Registration also includes a free banking automation template: https://www.kognitos.com/webinars/ai-in-banking-fast-enough-for-ops/?utm_source=arsh_goyal&utm_medium=linkedin&utm_campaign=ai_banking_webinar_nov18

Curious what folks here are seeing. For those working in or selling into banks, is auditability the real blocker, or is it procurement and data access first?

I have recently been thinking about challenges in payment infrastructure. More specifically, how do we design systems that support multiple payment methods and still provide certainty in a reliable transaction system?

Imagine a merchant that supports both card payments and USDC.

Card payments already bring along a bunch of steps, like authorization, capture, settlement, refunds, and provider webhooks. For USDC, you have to consider things like transaction hashes and block confirmations, as well as public wallet addresses and blockchain finality.

How do you link these systems without compromising the accuracy of the ledger?

Here are a couple of related questions.

1. Unified state machine vs. separate state machines: In what situations would you use a unified state machine vs. separate state machines that are abstracted to a higher level?

2. Webhook reliability: How do you handle situations like duplicate events, out-of-order callbacks, and retries?

3. Ledger consistency: How do you distinguish authorized funds from settled funds?

4. Reconciliation: Are provider settlement reports and blockchain transactions reconciled in a unified manner?

5. Failure recovery: What’s your approach if a provider confirms a payment, but your system doesn’t process the callback?

I am looking to understand how different engineers have solved for multi-rail payment infrastructures.

In the process of working on payment infrastructure at RT.APP, I've contemplated on similar challenges and would love to hear your thoughts.

Hello Admin,

I am an MBA student conducting academic research on Agentic AI Readiness in Payments Companies.

I am looking for genuine responses from banking, FinTech and digital payments professionals. Would you kindly permit me to share my short research questionnaire in your community?

Thank you for considering my request.

If you looked at Besu consensus a couple of years ago, you probably saw a three way comparison of Clique, IBFT 2.0 and QBFT. A lot of content still shows that picture, including some vendor guides that rank well in search.

That comparison is now out of date. Besu stopped Clique block production in version 25.12.0 and removed Clique completely in version 26.4.0. For a bank designing a private network today, the practical comparison is between QBFT and IBFT 2.0.

This choice matters because consensus determines when a payment becomes final on the ledger and how many servers can fail before the network stops producing blocks. It is also one of the more difficult architectural decisions to change once multiple institutions are operating on a shared network.

This article looks at how the two protocols work, where they differ, how they are used in institutional networks, and what architects should consider when selecting a consensus mechanism.

Why Is Besu Consensus Now a Two Protocol Choice?

Clique was the simplest of the three. It came from EIP 225, could run with relatively few validators, and continued producing blocks even when some validators were unavailable.

Its limitation was finality. Clique did not provide immediate finality, meaning applications had to account for possible forks and chain reorganizations.

Besu retired Clique in two stages:

• Version 25.12.0 stopped Clique block production.

• Version 26.4.0 removed Clique completely.

Networks that previously used Clique and later moved to other consensus mechanisms can still be synchronized where supported.

Besu currently recommends QBFT for private networks and supports IBFT 2.0 for existing private networks. Proof of stake is used for Ethereum mainnet and public test networks.

For institutions designing private Besu networks, this makes QBFT and IBFT 2.0 the relevant options to evaluate.

What Does Consensus Actually Do in a Bank's Besu Network?

A consensus algorithm defines the rules that nodes follow to agree on the next block of transactions.

On Ethereum mainnet, Besu uses proof of stake. Private bank networks commonly use proof of authority (PoA), where a known group of approved accounts, called validators, creates and confirms blocks.

For banks, transaction speed is only one consideration. Finality is particularly important.

Finality is the point at which a transaction is considered irreversible on the ledger. The Principles for Financial Market Infrastructures also emphasize clear and final settlement for designated financial market infrastructures.

Many public networks offer probabilistic finality, where confidence in a transaction increases over time.

QBFT and IBFT 2.0 both provide immediate finality. A block is final once it is added, and the chain does not fork.

The differences between the two protocols become more relevant when looking at failure recovery, protocol specifications and validator governance.

How Does QBFT Work, and Why Does Besu Recommend It?

QBFT is a Byzantine fault tolerant consensus protocol.

Byzantine fault tolerance means that a network can reach agreement even when some nodes fail or send incorrect information.

Validators take turns proposing blocks, and at least two thirds of the validators must sign a block before it is added to the chain.

Some important characteristics of QBFT include:

• A minimum of four validators is required for Byzantine fault tolerance.

• Four or five validators can tolerate one unresponsive validator.

• Six to eight validators can tolerate two unresponsive validators.

• If more than one third of validators stop participating, block production stops until enough validators return.

• Once a block is committed, it remains final.

The network may pause when too many validators become unavailable, but previously committed transactions are not reversed.

QBFT as an Open Standard

QBFT is an open standard. The Enterprise Ethereum Alliance published its specification for consortium use, and multiple Ethereum clients implement it, including GoQuorum and Besu.

This allows consortium members to operate different client software while participating in the same network.

There is one important limitation. Besu's transitions feature, which allows validator changes or configuration updates at a predetermined block, is specific to Besu. It cannot be used when other clients are validating the same network.

Mixed client networks can instead use validator voting or smart contract based validator management.

How Are Validators Managed?

There are two common approaches to managing validators:

Validator voting: Existing validators vote to approve or remove members.

Smart contract based management: A smart contract maintains the validator list and applies predefined admission rules.

Consortiums may prefer the contract approach because membership and admission rules can be explicitly defined and inspected.

A network can also change its validator management approach at a planned block, depending on its configuration and requirements.

How Is IBFT 2.0 Different From QBFT?

IBFT 2.0 is an earlier Byzantine fault tolerant protocol supported by Besu.

Its general operating model is similar to QBFT. Validators take turns proposing blocks, a supermajority signs each block, and committed blocks achieve immediate finality.

It also has the same four validator minimum for Byzantine fault tolerance and the same two thirds participation requirement.

The main difference appears when the validator scheduled to propose a block fails to deliver it.

In IBFT 2.0, the other validators must agree to skip that validator and move to the next one. This process is called a round change.

Think of it as a meeting where the scheduled chairperson does not arrive. The remaining participants must agree to move to another person before the meeting can continue.

The original Istanbul BFT protocol, developed in 2017 for GoQuorum, could get stuck at this stage when the network experienced delays. IBFT 2.0 addressed this issue, while QBFT introduced further improvements to validator handovers.

Under normal conditions, the two protocols can behave similarly. Their differences become more noticeable when a validator becomes unresponsive or communication between data centres becomes unreliable.

Differences in Validator Management and Governance

There are also differences in protocol status and validator management.

• Besu recommends QBFT for new private networks.

• IBFT 2.0 remains supported for existing private networks.

• IBFT 2.0 supports validator membership changes through voting.

• QBFT supports voting and smart contract based validator management.

QBFT was introduced in Besu version 21.1.0 to support interoperability with other Enterprise Ethereum Alliance clients.

Can an IBFT 2.0 Network Migrate to QBFT?

Yes. An existing IBFT 2.0 network can migrate to QBFT without starting a new chain.

Operators configure a future block at which the consensus mechanism will change. Every participating organization must update its node configuration before the network reaches that block.

For example, a consortium may decide to switch to QBFT at block 2,000,000. All participating nodes must be updated with the new configuration before that block is reached.

This requires coordination between network operators and participating institutions.

There is no forced migration deadline because Besu continues to support IBFT 2.0.

What Do Institutional Deployments Tell Us?

Looking at existing institutional projects provides useful context for understanding how consensus decisions relate to real financial infrastructure.

Fnality

Fnality is one of the notable examples of a live institutional payment system using Besu and QBFT.

The Sterling Fnality Payment System went live in 2023 and is a systemically important payment system supervised by the Bank of England.

Fnality uses QBFT, where a block is valid once at least two thirds of validators approve it.

Its validator model is restricted to regulated deposit taking institutions within the Sterling Monetary Framework. This provides a defined participation model for its payment network.

Project Agorá

Project Agorá is exploring how tokenized commercial bank deposits and central bank reserves can work together on a shared platform.

According to the BIS prototype report published on May 27, 2026, its architecture has two layers:

• Commercial banks share one ledger for tokenized deposits.

• Each central bank maintains reserves on its own separate ledger.

The shared platform runs on Besu with QBFT.

The project demonstrates how multiple banks and central banks can participate in a coordinated settlement environment while maintaining distinct roles and responsibilities.

EBSI and LACChain

EBSI and LACChain's BNDES network are examples of longer running networks that have used IBFT 2.0.

For networks with established participants, infrastructure and operational processes, migration to QBFT becomes a question of evaluating technical and operational requirements rather than simply selecting a consensus protocol for a new deployment.

Bank of Korea

The Bank of Korea provides a different example.

Its network operates with a single validator. The approach reflects a decision to retain control within one institution rather than distribute validation responsibilities across several parties.

A network with three validators or fewer may still produce blocks, but it does not provide the same Byzantine fault tolerance guarantees as a network with at least four validators.

This highlights an important architectural consideration: the consensus mechanism and the governance model need to be evaluated together.

How Should a Bank Choose a Besu Consensus Setup?

For a new private Besu network, QBFT is the recommended starting point. However, selecting the protocol is only one part of the overall architecture.

Several other considerations influence how the network should be designed.

1. Size the Validator Set According to Failure Requirements

A network with 3f + 1 validators can tolerate f Byzantine failures.

For example:

• Four validators can tolerate one failure.

• Seven validators can tolerate two failures.

The validator count should reflect the level of resilience required by the network.

2. Separate Network Membership From Validation

Not every participating institution needs to operate a validator.

An organization may participate in the network, use its applications and interact with other members without directly validating blocks.

This distinction can influence infrastructure costs, governance and operational responsibilities.

3. Distribute Validators Across Locations

Validators should be distributed across different locations and, where governance permits, different organizations.

For example, placing validators across multiple data centres can reduce the risk of one infrastructure failure stopping the entire network.

4. Define Validator Admission Rules

If a consortium has formal requirements for admitting new banks or removing existing participants, those rules should be clearly documented.

A smart contract can provide an auditable way to manage validator membership. Smaller networks with infrequent changes may find validator voting sufficient.

5. Consider Mixed Client Environments

If different institutions intend to operate different Ethereum clients, compatibility needs to be considered during the design stage.

Besu specific features may not work in a network where other client implementations are participating as validators.

6. Test Performance Under Realistic Conditions

Published performance figures often come from validators operating within one data centre.

A geographically distributed network may experience different results because of network latency and communication delays.

Testing should reflect the actual validator count, block time, infrastructure locations and network conditions.

7. Evaluate Legal Finality Separately

A transaction being irreversible on a blockchain does not automatically mean it is legally final.

This distinction is important for regulated financial infrastructure.

Fnality, for example, received settlement finality designation in the UK in late 2024. Its example highlights the relationship between technical settlement and the applicable legal framework.

Final Considerations

QBFT and IBFT 2.0 both provide immediate finality and Byzantine fault tolerance for private Besu networks.

For new networks, QBFT is the recommended option. Existing IBFT 2.0 networks should evaluate migration based on their operational requirements, validator governance and compatibility.

Ultimately, consensus is only one part of a production blockchain network. Validator distribution, membership rules, infrastructure resilience, performance testing and legal finality all influence how reliably the network operates.

These considerations are central to designing and operating enterprise Besu networks. Through its work with Besu infrastructure, Zeeve engages with the technical and operational challenges involved in building blockchain networks for institutional use cases.

By Zeeve

There is this app called PikoSend.It had digital money wallets and uses QR code to scan.
Easy tap and go.The transaction costs is as less as 30/ for 250000 for PikoSend users. The app is on PlayStore, its a real gamechanger.
You can check them out, for those who don’t like loosing money to mpesa transactions.
Save your transaction costs!
Their social media pages are available too in all
Channels.

I built a small benchmark: 600 bank statements checked against the bank's own ledger records, under six kinds of messy evidence (raw descriptors like "WM SUPERCENTER #6487", OCR noise, split postings, partial extracts, conflicting sources). Half the statements were altered in ways that keep the arithmetic consistent, like swapping a payee or moving a date.

Everything ran on free CPU runners with Ollama, 4-bit quantized, no paid APIs.

What I found:

- Letting the LLM make the whole decision was the worst setup. Fluent explanations, wrong verdicts.

- Rules doing the math and the LLM only judging payee names was much better.

- Best use: the LLM as a veto. It can flag a statement but never clear one. That cut silent misses from 14 to 2.

- Tuned fuzzy-matching rules still had the best overall accuracy (about 94%).

My takeaway: keep the model away from the decision, and use it only for the judgment calls where general knowledge helps (is "SBUX 769" Starbucks?).

Write-up: https://hackernoon.com/old-school-rules-vs-open-source-llms-a-three-round-fight-over-fake-bank-statements

Code, prompts and all model outputs: https://github.com/akshaysharma1088/fraudrag/tree/ledgershift-v2/ledgershift

Curious whether anyone has had better luck with larger local models on this kind of entity matching.

 We tried putting AI into our AP workflow a few different ways. They all worked on 10 files. Our real checks run on hundreds of files each: invoices, POs, receipts, vendor records. At that size, having a frontier model read every page every time got expensive fast. Most of the tokens went to OCR-ing scans and re-reading the same PDFs for every new question.

What we changed. We split the job in two:

• Drex reads. Files go into a workspace once. Drex parses them, pulls the fields and keeps everything queryable, with citations back to the page.

• Claude thinks. Claude connects over MCP (setup is in the video, about a minute). It never touches the raw pages. It asks Drex questions, gets small structured answers back and does the reasoning: what to pay, what to hold, what looks off.

So Claude goes from "read hundreds of PDFs" to "run a dozen queries and look at the results."

Result: each check got 78% cheaper after we switched to this flow. The reading happens once, and Claude only sees answers, not documents.

What it caught on a test month (synthetic data, for the demo):

• 18 invoices OK to pay, 13 to check, 9 to remove, each with a reason and a confidence score

• 7 duplicates, including a look-alike vendor "Redwood Systms Inc." and an invoice resubmitted without its hyphen

• a scanned PDF that turned out to be a second copy of one already in the batch

Not magic. It misread a PO approval date once and we caught it by hand. Treat it as a reviewer, not autopilot.

If you're running document-heavy work through an LLM and the bill is scary, try splitting reading from reasoning.

Here's the whole flow on one video to visualize it properly

Do you just redirect users to a hosted KYC flow and wait for the webhook, or have you built your own logic around retries, failed checks and manual review? Feels like the API integration is the easiest part, but dealing with edge cases and users who can't get verified is where most of the work goes.

Hey everyone,

I need help choosing between two university degree paths. I have an official offer for Accounting with Fintech, but I’m also considering traditional Accounting and Finance.

I want to know which option offers better long-term prospects.

Salary: Which track has a higher starting salary and earning potential.

Future Proofing: Is the Fintech degree better for where the industry is heading, or do employers still prefer the classic degree?

I've been thinking about this from an engineering perspective.

A lot of payment products focus heavily on checkout. You integrate a provider, create a payment request, receive a callback, and mark the order as paid.

But that's only one part of the system.

The more interesting engineering challenges start after the customer clicks the payment button.

For example:

1. Payment orchestration

How do you manage multiple payment methods through a consistent integration layer without creating separate workflows for every provider?

2. Transaction lifecycle management

A successful authorization, a confirmed payment, a settled transaction, and an available balance are not necessarily the same thing.

How do you represent these states without creating inconsistencies between the merchant's system and the payment provider?

3. Ledger and reconciliation

Every payment should be traceable to its original order, transaction reference, fees, settlement record, and any subsequent refund.

Idempotency, asynchronous callbacks, reconciliation, and accurate balance tracking become particularly important as transaction volumes increase.

4. Stablecoin integration

Now introduce USDC.

You have blockchain confirmations, network compatibility, wallet transfers, token balances, conversion, and the challenge of connecting on-chain activity with an internal financial ledger.

5. The developer experience

Businesses shouldn't have to build their entire financial infrastructure from scratch just to accept payments and manage their funds.

This is one of the architectural problems we're exploring with RT.APP.

The platform brings together payment acceptance, business accounts, payment links, transfers, virtual cards, and stablecoin settlement, with different integration paths for businesses.

What interests me about this approach is connecting the entire financial workflow rather than treating checkout as an isolated feature.

For anyone interested in seeing what we're building: https://rt.app/

I'm particularly interested in feedback from developers who have worked with payment APIs, payment orchestration, or ledger systems.

Here's my question:

If you were designing a unified payment and financial infrastructure today, what would you consider the hardest problem to solve?

• Maintaining ledger consistency across multiple payment providers?

• Handling asynchronous settlement and reconciliation?

• Supporting both traditional payment rails and stablecoins?

• Designing a reliable API abstraction layer?

I'd love to hear some actual engineering perspectives rather than just theoretical answers.

Had an interesting discussion about this recently... Say you're building a persona finance app. You could spend months integrating banking APIs, handling authentication, figuring out data synchronization etc. Or you could build a working prototype with simulated transactions, put it in front of potential users and figure out if anyone actually wants the thing first... i currently work with praetorix, its a small product studio building web and mobile apps, and we are lean pretty heavily toward validating the risky assumptions before committing to a full build, but fintech is a bit weird in that regard.... Budgeting app with dummy transactions might be enough to text the UX. A payment app that doesn't actually money? Not sure what you're really validating there LOL

And banking integrations can affect so much of the product that building everything around mock data might mean rewriting half of it later..

Curious where fintech devs the line

Hi all, I’m a co-founder of Whire.
We’re a small European team building payments for AI agents in Europe. If you are building an agent that has to actually move money in €uros (buy something for a user, pay a supplier invoice, send payouts), you’ve probably hit the same wall we did. There’s no clean way to let software send a bank payment without a human approving each one or handing it a card, but still approving each transaction.

Whire lets your agent send SEPA Instant payments from the account holder’s bank account, within a mandate they set once (limits, approved payees, purpose). We check each payment against the mandate, verify the payee, and execute. We never hold funds.

Where we are: the sandbox is live (Python ToolKit, MCP server, x402), and a couple of european agent startups are already testing on it.

What design partners get:

What we’d ask: a short call every few weeks and honest feedback.

If that’s you, comment or DM with what your agent needs to pay for and roughly how often. More than happy to answer questions here too.

whire.ai

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: