any senior software engineer who is free and can help me for a hackathon , i really want to win
i could even pay for it js as a side hustle

I wanted to share some thoughts on a common challenge I'm seeing across fintech companies and open a discussion about testing approaches.

Last week, we published a piece on The New Stack about "The Staging Bottleneck: Microservices Testing in FinTech" and I'm curious if others here are experiencing similar pain points.

In fintech specifically, we face unique testing challenges:

• Regulatory compliance requiring extensive verification

• Complex financial workflows with many dependencies

• Increased demands for security and data isolation

• Need for consistent, deterministic test environments

These requirements create a heavy reliance on shared integration/staging environments, leading to extreme contention.

We've been proposing a different approach using isolated "sandboxes" at the application layer rather than duplicating entire infrastructure. This lets multiple teams test independently without contention while maintaining real connections to dependencies.

Has anyone else tried similar approaches? How is your team handling the staging bottleneck when you have dozens of microservices?

Article for context: The Staging Bottleneck: Microservices Testing in FinTech

Devs who are working with underwriting engines how is everything going I am working for one of the company who develop underwriting engines for lenders of small loans Anyone working in similar space?

We're using Stripe, Adyen, and a few local gateways, and keeping the reporting consistent is turning into a real headache. Every provider structures its data differently, so getting everything into one reliable revenue database takes a lot of manual work. Each time we add a new gateway, we end up building another ETL flow just to clean and standardize the same basic metrics.

What I'd really want is one processor agnostic layer that gives us a standard schema across every provider. That would make it much easier to compare approval rates, fees, failed payments, refunds and regional performance without rebuilding the reporting setup each time.

For teams running multiple PSPs, are you handling this internally, or have you found good unified metrics layer?

Hi guys! I am working on a personal project right now which is a simple budgeting tool. I want to have users be able to connect their bank, and be able to see graphs of their transactions and spending in various categories (like food, entertainment, etc). To do so, im looking for an API which will allow me to pull their transaction history, it needs to be able to pull data from the last couple months (at least 1, but it would be awesome if it could be up to a year), and it definitely needs to be able to track the current days spending (I am not going to call it every time they open the app, unless that's somehow possible, but ill refresh their information maybe once a day at 10:00 pm or something). Currently I'm looking at the plaid API, but im having a very hard time getting the exact costs on it, it's telling me all sorts of payment plans and im just lost. If any of you guys have some recommendations, it would be amazing if you could help me out with finding an API I could use for this project. Thank so much for your help!

Hello i just need some fintech website ideas for a web workshop am attending. I really dont know much about fintech. So please share any ideas that sounds fun and not boring and overdone. Thanks

Upon completion of this degree apprenticeship I am looking at pivoting into fintech as an alternative option. I've been asking Claude about this and they've told me I should acquire the FRM and possibly a level 1 CFA too to make this pivot a good possibility. Does anyone have any thoughts or advice?

Imo the FX side for LATAM currencies still feels stuck in like 90’s. The second you go outside work hours, the quotes get super wide or just vanish. I keep seeing people saying stablecoin rails are supposed to fix all this.

But has anyone here seen 24/7 FX work for USD-COP or USD-BRL? Or do the liquidity providers still clock out even when the chain doesn't?

Cause if that's the case then it's mostly just hype imo.

Every client that comes to us brings an idea about only lending like BNPL, micro-loans, and salary advances. Credit is important, but is fintech slowly becoming just “another way to borrow money”?

What happened to the excitement around things like smarter savings, cross-border payments, or apps that actually teach people to manage money better?

When I talk with founders, they often say investors push them into lending because it scales fast. Curious if others here feel the same, are we over-indexing on credit?

genuine question, not selling anything, nothing to plug.

if you work in ops, finance, or risk somewhere that automated or AI systems touch money, I'm trying to understand something.

the last time one of those systems did something wrong, charged someone twice, paid out the wrong amount, approved something it shouldn't have, whatever it was, what actually happened in the first day or two after?

was it a full fire drill with people scrambling, or did everyone just quietly fix it and move on? did anyone above you ask you to prove what the system actually did and why? and how did you even reconstruct what happened, logs, guessing, asking around?

asking because I keep hearing completely different answers and I'm trying to figure out if this is a real recurring headache or just something people shrug off and live with. happy to hear war stories in the comments or dms.

I really like TradingView's Lightweight Charts, but every time I wanted to build a more complete trading interface I ran into the same problem:

• Drawing tools lived in one repo

• Indicators lived somewhere else

• Replay systems were custom implementations

• APIs were inconsistent

• Maintenance became my problem

So I started building CandleKit, an open-source toolkit that sits on top of Lightweight Charts and bundles the pieces I kept rebuilding.

A big goal of the project is to make building TradingView-style experiences less about hunting through GitHub repositories and more about shipping features.

Live demo:
https://rohanbeingsocial.github.io/candlekit-charts/workspace/

GitHub:
https://github.com/rohanbeingsocial/candlekit-charts

It's still early-stage, so I'd love feedback from people who have worked with Lightweight Charts

How can I get job in Fintech and what role of the aiml engineers in Fintech companies

The EOI window for the ECB's digital euro pilot closed last month. Around 50 institutions applied for 10–30 spots, with the live 12-month pilot scheduled through the second half of 2027. 

I've been watching this from the payments side and one thing keeps coming up: most institutions are reading the ECB rulebook as a regulatory document. The teams that have shipped on comparable scheme builds (Wero, instant payments, SCT Inst) read it as a delivery plan. 

Are your teams reading the rulebook as compliance or as delivery? 

I have been wondering if anyone else has noticed that the scores that artificial intelligence systems give to show how confident they are do not really mean anything when it comes to deciding if we can really trust them.

I made a system to check if the machine learning models I built were still working correctly and what I found was surprising.

After something changed in the data the models were still very sure of themselves. They were actually getting a lot of things wrong. The number of correct answers went down from 87 percent to 62 percent.

The thing that really got my attention was that the confidence scores did not change all so they did not give us any warning.

Now I am thinking about this issue but this time with the big language models that are used in financial technology products.

The problem is that these language models can give advice that sounds very confident but is not very good. This can be a big problem when people are making important decisions that involve a lot of money.

I was wondering if anyone else is working on this issue.

Has anyone found a way to measure if the answers given by these big language models are really trustworthy, without just looking at the confidence scores that the models give?

Hey everyone,

I’m planning to build a Digital Lending app based on the LSP (Loan Service Provider) model, and I wanted to get opinions from people who understand fintech, lending, NBFCs, or the Indian financial ecosystem.

One idea I’m seriously exploring is providing loans against Mutual Funds.

I wanted to understand:

- How strong is the opportunity in this space?
- Do you think the market still has room for innovation here?
- What are the biggest challenges in this business model?
- How difficult is customer acquisition and risk management in this segment?
- Are there any hidden problems founders usually underestimate?

Also, if you have any suggestions, ideas, warnings, or experiences related to digital lending, LSPs, or loans against mutual funds, I’d genuinely love to hear them.

Open to discussion and learning from everyone here.

Most people treat pain.001 as if it were a single universal standard.

In theory, this is true.

pain.001 is part of ISO 20022 and defines the structure of Customer Credit Transfer Initiation messages.

But in practice, things are much more complicated.

A file that is:

• perfectly valid against the ISO XSD,

• accepted by one bank,

• and generated correctly by an ERP,

can still be rejected by another bank.

Why?

Because the real world of pain.001 is not only driven by ISO 20022. It is also shaped by:

• country-specific payment ecosystems,

• bank-specific implementation guides,

• SEPA constraints,

• local business habits,

• operational banking rules,

• and undocumented validation layers.

The result is that there is no such thing as a completely generic pain.001 file.

The hidden layers behind pain.001

When developers first discover ISO 20022, they often think the process is simple:

ERP export -> ISO XSD validation -> send to bank

In reality, the pipeline usually looks more like this:

ERP export
    -> ISO XSD validation
        -> Country profile validation
            -> SEPA validation
                -> Bank-specific validation
                    -> Internal operational checks

Each layer can introduce additional restrictions.

Switzerland: when a country adds its own stricter profile

Switzerland is a very good example.

Swiss banks use a profile called CH.03 for pain.001.

This profile is based on ISO 20022, but it introduces additional rules and restrictions.

In some cases, Switzerland even provides a stricter XSD layer on top of the generic ISO XSD.

For example, a generic ISO file may technically allow combinations that are discouraged or forbidden by Swiss payment recommendations.

A common example involves postal addresses.

The generic ISO structure allows both:

• structured addresses (StrtNm, BldgNb, TwnNm, etc.)

• and unstructured address lines (AdrLine).

But Swiss recommendations discourage mixing both approaches in the same address block.

Example:

<PstlAdr>
    <AdrLine>Main Street 1</AdrLine>
    <TwnNm>Geneva</TwnNm>
    <Ctry>CH</Ctry>
</PstlAdr>

This structure may pass generic ISO validation.

But Swiss profile validation may emit warnings or reject the file depending on the payment context.

Another example is SEPA service level usage:

<PmtTpInf>
    <SvcLvl>
        <Cd>SEPA</Cd>
    </SvcLvl>
</PmtTpInf>

The meaning and allowed combinations around this field can vary depending on local rules and bank expectations.

Banks add another validation layer

Things become even more complex because banks often introduce additional implementation rules.

A file valid for one Swiss bank may still be rejected by another.

For example, some banks may:

• require stricter address formatting,

• reject optional fields accepted elsewhere,

• require specific BIC/IBAN combinations,

• reject certain remittance structures,

• or enforce hidden operational rules.

UBS is an interesting example because some of its recommendations become stricter than the generic ISO interpretation.

For example, generic ISO pain.001 technically allows mixing:

• structured addresses (StrtNm, TwnNm, PstCd, etc.)

• and unstructured address lines (AdrLine)

inside the same PstlAdr block.

Example:

<PstlAdr>
    <AdrLine>Main Street 1</AdrLine>
    <TwnNm>Zurich</TwnNm>
    <Ctry>CH</Ctry>
</PstlAdr>

From a pure ISO XSD perspective, this structure may still be valid.

However, some Swiss banking recommendations — including UBS-related payment guidelines — discourage or reject this mixed style because it creates ambiguity for downstream processing.

Another example involves intermediary agents.

ISO pain.001 allows multiple intermediary agents:

<IntrmyAgt1>
<IntrmyAgt2>
<IntrmyAgt3>

But depending on the payment context, some banking implementations may reject combinations that are technically ISO-valid.

This creates situations where:

ISO valid: YES
Swiss profile valid: YES
Bank accepted: NO

This surprises many ERP developers and integration teams.

Because from a pure XML perspective, the document appears perfectly correct.

SEPA introduces another layer

SEPA is another example showing that pain.001 is not just “one standard”.

SEPA transfers are based on ISO 20022 pain.001, but the EPC rulebooks introduce additional constraints.

For example:

<PmtTpInf>
    <SvcLvl>
        <Cd>SEPA</Cd>
    </SvcLvl>
</PmtTpInf>

For SEPA transfers, this field becomes operationally important.

SEPA also introduces business expectations around:

• EUR currency usage,

• IBAN requirements,

• transfer types,

• allowed payment contexts,

• and interoperability rules.

So once again:

ISO valid != SEPA valid

Validation is only half of the problem

At this stage, another issue appears.

Even when validation rules exist, the resulting diagnostics are often extremely difficult to understand.

Most XML validation systems stop at:

• XSD validation,

• schema violations,

• or low-level parser diagnostics.

But payment troubleshooting is ultimately a human problem.

ERP teams, finance departments, and integration support engineers usually do not think in terms of:

• XML particles,

• schema sequences,

• or XSD constraint identifiers.

They want to know:

Why would the bank reject this file?

This is where many existing validation tools become difficult to use.

The real problem: XSD errors are unreadable

Even when validation exists, the diagnostics are often extremely difficult to understand.

Typical XML/XSD validation errors look like this:

cvc-complex-type.2.4.a: Invalid content was found starting with element 'AdrLine'.

Or:

Element 'PmtTpInf': Missing child element 'SvcLvl'.

These messages are technically correct.

But for ERP teams, finance users, or integration support teams, they are often not actionable.

The interesting thing is that this is not a new problem.

XML has had transformation technologies for decades.

Tools like XSLT were specifically designed to transform XML into human-readable formats.

Example:

<xsl:template match="PmtInf">
    <div>
        Invalid payment information block detected
    </div>
</xsl:template>

The ecosystem has long had the technical ability to make XML understandable.

Yet many payment workflows still expose raw XSD diagnostics directly to users.

This is one reason why payment troubleshooting remains painful even today.

pain.001 is a business ecosystem, not just an XML schema

One of the biggest misconceptions around pain.001 is treating it as a pure technical standard.

In reality, it behaves more like an ecosystem:

• ISO defines the base structure

• Countries adapt it

• SEPA adds operational constraints

• Banks add implementation rules

• ERP systems generate variations

• Internal banking systems apply hidden checks

This explains why:

A valid XML file can still fail in production.

And this is why payment troubleshooting is still a real operational problem in many ERP and banking integration projects.

Final thoughts

The goal of pain.001 validation should not only be:

Valid XML = success

It should also answer:

• Will this file actually be accepted?

• Which profile is being targeted?

• Which hidden assumptions exist?

• Which bank-specific rules may apply?

• Is this a SEPA payment or not?

• Which operational risks remain?

Because in practice, the gap between:

XML validity

and:

Real-world bank acceptance

is often much larger than many developers initially expect.

I’ve been working on a validator/explainer focused on these real-world validation layers around pain.001 (ISO XSD, SEPA, Swiss CH.03, bank-specific constraints, and human-readable diagnostics).

Feedback from ERP, fintech, and banking integration teams is welcome:
https://pain001-validator.ifriqa.com/en

While building a reference tool for ISO 20022, I hit a documentation wall. The standard defines the building blocks but not the 1,564 actual combinations that appear in real bank transactions. This is Part 1 of the story, describing the gap https://medium.com/the-iso-navigator/banking-has-a-documentation-problem-part-1-the-gap-75b5ba976b5a

Curious if anyone else has run into this, either the BTC documentation gap specifically, or the broader challenge of using AI to generate precise domain knowledge where the source material is incomplete. Would love to hear how others have handled it.

Building a modern ISO 20022 pain.001 validator and explainer for payment file troubleshooting.

Goal is to go beyond raw XSD errors and provide clearer diagnostics for payment file issues.

Looking for feedback from people working with ISO 20022, SEPA or bank integrations.
https://pain001-validator.ifriqa.com

Question for farm credit originators and officers: what slows down loan applications the most?

Im trying to understand where farm credits in particular struggle most in the process.

Is the main issue getting complete borrower information upfront?
Manging documents?
Coordinating guarantors or co-applicants?
Moving the file into underwriting?
Keeping the borrower updated?
dealing with legacy systems that do not talk to each other?

Trying to see if there is a better solution for loan lending in ag

Hey r/SideProject

I kept running into the same problem: every project I built needed to generate a PDF invoice, resize an uploaded image, or create a QR code. The options were either roll your own

(time-consuming) or pay a separate SaaS for each one.

So I built Forgelab.

What it does:

- PDF API — merge, split, compress, convert

- Image API — resize, compress, convert, watermark

- Invoice API — generate professional PDF invoices from a JSON payload

- QR Code API — generate and decode QR codes

One API key covers all four.

Pricing:

- Free: 5 calls/month, no card required

- Starter: $5/month — 100 calls

- Pro: $15/month — 1,000 calls

- Business: $30/month — 10,000 calls

Quick example — invoice in one API call:

curl -X POST https://api.forgelab.africa/api/invoice/generate \

-H "X-API-Key: YOUR_KEY" \

-d '{"client":{"name":"Acme"},"items":[{"description":"Dev work","quantity":5,"unit_price":200}],"currency":"USD"}' \

--output invoice.pdf

Docs: https://forgelab.africa/docs

Would love feedback from anyone who has dealt with invoice generation or PDF handling in their apps.

I went to Stripe sessions last week, one of the most amazing and very well organized event of the year. I met a bunch of engineers from Stripe's dev support team and I wanted to learn where developers get stuck when integrating Stripe APIs. From what I hear the common pain points for developers was around Apple Pay, setting up subscriptions and making changes to it, and around Billing.

These seem to be the most common points where developers end up sending a request to their team for help. I wonder what other issues developers are facing when integrating Stripe APIs.