r/fintechdev

https://preview.redd.it/g3h65ltymsjh1.png?width=767&format=png&auto=webp&s=e01808b3b6d935d47ae5d9f5c8300345c72fabed

A business team wants to test something. They pull a customer list, split it in half, and run the test. That split is usually where it goes wrong.

Splitting randomly across the whole base can leave one group with more customers from a specific profession, region, or education level than the other. When the results come in, nobody can tell whether the difference came from the test or from the composition of the groups.

There is also the sample size question, which most teams skip entirely. If the base is too small to detect the effect you care about, the test will come back inconclusive no matter how well you run it. That is a calculation you do before, not something you discover after two weeks of waiting.

I built a pipeline that handles this part: upload a customer base, get back two stratified groups with proportional composition, the minimum sample size backed by power analysis, and a statistical check (t-test and chi-square) proving the split was fair. Output is two CSV files plus a plain text summary the business team can actually read.

Tested it on a bank marketing dataset with 11k customers. Stratified by profession, marital status and education, the resulting groups came back with p-values above 0.99 across every variable, meaning no meaningful skew in either direction.

Hub: https://aiforfintech.tech
Github: https://github.com/junidepieri-design/expd-001-ab-test-design-pipeline

How does your team handle the split when designing a test?
👊

I'm trying to grasp a better idea on how people structure the fraud layer around card authorization without making the authorization path too heavy. Velocity and hard spending limits seem easy enough to evaluate immediately but things like merchant patterns, relationships between multiple cards and activity across the wider program seem like they'd require more context in my opinion.

I'm leaning toward keeping high confidence checks in the authorization path and doing the heavier analysis separately then feeding those results back into future authorization decisions.

People who built something similar could you guys give me some context or idea on how you split the real time controls from the broader monitoring layer? Thanks in advance.

​

We’re looking for an experienced backend/full-stack developer to help complete and verify an authorized white-label API integration inside an existing fintech platform.

The platform already exists. We are not looking for someone to rebuild the backend from scratch. We need someone who can understand an existing codebase, integrate the provider’s white-label API correctly, fix remaining issues, and test the complete flow.

Stack: Next.js, TypeScript, Node.js, Supabase/PostgreSQL, Vercel, GitHub, Admin Dashboard, Hosted Checkout, webhooks, and reconciliation services.

How the Ramp Engine should work

Customer opens Hosted Checkout → Ramp Engine collects the transaction requirements → backend calls the white-label API → available countries/payment methods/providers are returned → quotes are requested → best/selected provider is launched → transaction status is tracked → webhook/reconciliation confirms finality → merchant is notified.

The developer should be comfortable working with API flows such as:

Bootstrap / initialization

Supported countries

Available payment methods

Provider availability

Quote generation

Provider selection

Checkout/session launch

Transaction status

Signed webhooks

Idempotency

Reconciliation

Finality processing

Settlement records

Merchant notifications

Credentials and API keys must remain server-side only and must never appear in browser code, logs, Git history, or public messages.

You will first review the repository, existing architecture, Admin controls, database, and audit reports before making changes. Working components should be preserved rather than unnecessarily rebuilt.

We also need proper testing, including unit tests, API integration tests, PostgreSQL tests, concurrency/idempotency tests, webhook security tests, typecheck, lint, build, and deployment verification.

During development, all live transaction controls remain OFF. No real financial transaction or customer-fund activity is required.

Who we’re looking for

Please message me if you have strong experience with:

Next.js / TypeScript / Node.js

PostgreSQL / Supabase

Complex third-party or white-label API integrations

Payment/ramp/fintech APIs

Signed webhooks

Idempotency and duplicate-event protection

Reconciliation systems

Secure API credential handling

Existing production monorepos

When contacting me, please briefly explain similar integrations you have completed, your experience with webhooks/reconciliation, and provide relevant GitHub or portfolio examples if available.

We are specifically looking for someone who can understand the existing architecture and finish the integration correctly, not someone who wants to replace everything with a new system.

Most remote onboarding in the EU today runs on document capture plus a liveness check, and eIDAS-compliant electronic identification tends to be available as an option rather than set as the default. The draft language flips the burden, so the non-eIDAS route becomes the one that needs explaining.

How much of a change that is in practice seems to depend entirely on where a firm already sits. For those offering an eID path alongside document checks, it may come down to documentation. For firms operating in markets where eID coverage is thin, it could mean rebuilding the flow.

Interested in how others are reading it. Where does remote onboarding sit for you today, and does the justification requirement look like a real obstacle or a paperwork one?

I’ve been researching development partners for a fintech product recently, and one thing I’ve realized is that choosing a software company for fintech is quite different from choosing a general development agency. A company can be excellent at building mobile apps or web platforms, but that doesn’t necessarily mean they understand the challenges that come with financial products.

For fintech, I think the technical side is only part of the equation. You’re dealing with sensitive financial information, integrations with banking or payment systems, security requirements, scalability, and often regulatory considerations as well. On top of that, the team needs to understand the actual product and the users rather than simply taking a set of requirements and turning them into an app.

I’ve also been looking at companies like GeekyAnts and how their experience across fintech and emerging technologies fits into this space. I’m especially curious about newer technologies such as AI. There are plenty of companies now describing themselves as “AI-powered,” but I’m more interested in whether they can actually use AI where it makes sense, without adding it just because it sounds impressive.

For anyone who has hired an external development company for a fintech or banking product, what did you look at before making the decision? Did previous fintech projects matter more to you than technical expertise, pricing, or the size of the team? And after working with them, was there anything you wish you had evaluated before hiring them?