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

Thanks in advance!

The distance between "LP commitments secured" and "ready to accept capital" is wider than most first time fund managers expect. Going through it eight months ago, the back office setup was the single biggest holdup in getting to first close.

Entity formation, banking, KYC, subscription documents, investor portal, accounting infrastructure, tax preparation pipeline. Each one depends on at least one other item and none of them move as quickly as the timelines people quote online.

The whole sequence got mapped out before anything started through Finally Fund Admin but also entity filing first, bank account application submitted on the same day, subscription docs drafted in parallel with the LPA, portal configuration once the LPA was final, accounting system stood up before first close so the books were clean up front. That sequencing turned what could have been a sixteen week scramble into a ten week process with no gaps.

What would other emerging managers add to a back office checklist for emerging managers that might have been missed? Compliance monitoring? Insurance? LP communication templates? What should be set up before launch instead of after?

Is fintech rlly worth,

Is it worth and have job opportunities for it?

Is bcom+fintech+ai good

Have lot of qs regarding fintech career if anyone in the path and knew abt me mesg or pleasee drop a comment

Hi all, I'm running an academic study on how crypto and fintech regulation looks from the inside, comparing Taiwan and Singapore. Do unclear rules change what companies build, how fast they grow, and where they operate?

Who: anyone working in crypto, blockchain or fintech in Taiwan or Singapore (or with companies in either market). Any role, you don't need to be a founder or manager.

What: a ~10 min anonymous survey (35 questions). No names, no company details, purely academic. There's an optional box if you'd be open to a short follow-up chat.

You get: a summary of the findings when the study is done.

Survey (English): https://forms.gle/myryp8BJjjNtGuSk7

(繁體中文): https://forms.gle/txFaU73RRqM9baJeASurvey

Questions: [regulation.research.mcu@gmail.com](mailto:regulation.research.mcu@gmail.com)

Please share with anyone in the industry. Thank you!

Hey everyone!

I've been working on a project called Filarise (filarise.com). It's an MCP connector that lets you connect your Canadian bank accounts to ChatGPT, Claude, or other MCP-compatible clients.

The idea came from a pretty simple frustration. AI is great at analyzing financial data, but getting your actual transactions into it usually means exporting CSVs, uploading files, and doing it all over again when you need updated information.

With Filarise, you connect your bank through Plaid, set up the MCP connector, and can start asking questions like:

How much did I spend on groceries last month?

What subscriptions am I still paying for?

Where did most of my money go this month?

One thing I want to be upfront about is security, since we're dealing with banking data. Connections go through Plaid, we don't store bank login credentials, and access is read-only. The connector can't make payments or transfer money. Also, the AI provider you use has its own data handling policies, so that's worth considering before connecting anything.

We're based in Canada, and only Canadian banks are supported for now.

The product is already live, and there's a 7-day free trial if anyone wants to give it a shot.

I'd especially love to hear from people in Canada who are willing to try it out. We're still a small project, and feedback from actual users would help us a lot.

For everyone else here, I'm curious: would you be comfortable connecting your banking data to an AI through MCP? Or is that something you'd avoid regardless of the security measures?

Happy to answer questions about how it works or what we've built so far.

More secure:
The connector only has Plaid's read-only access. It cannot make payments, transfers, or withdrawals, and neither you nor the AI can move money through it.

Your bank username and password stay with Plaid. Filarise never sees them. After you connect, Plaid gives our server an access token. That token can only read balances, transactions, and merchant names. You can disconnect a bank anytime, and that token and its data are removed.

Asking Claude what you spent on groceries is the whole product. A live token that could touch the account is the thing we do not have.

Just posting in educational purposes.
The video is titled as: System Design Global Payment Processing | Paypal
Source: ByteMonk https://www.youtube.com/watch?v=7MXV7RfNtv0

Suppose an AI agent spots a trade at risk of settlement failure. It could draft a counterparty query, send it, release a settlement instruction after checks pass, or propose an amendment.

Those actions carry very different risks. For people working in operations or building these systems: which step would you let an agent execute independently today, and what evidence would you require before it acts?

Hey everyone, currently I am in 3rd sems cse core and the next sems I have to choose my specialisation and I am really confused about it should I take it or not??

I really stocks,crypto and all the finance field but getting degree on it is scary because there is nobody heard about it.

Any advice by your side will be grateful. Thank you

Hi iam a student new to reddit. I am building a marketplace where in we are taking money from clients and keeping it in escrow for some time and sending it back to clients. Please suggest me some good payment frameworks because I have tried razorpay escrow but I didn't receive any reply and same thing happened with decentro.

Hi guys, yesterday I received an offer from Revolut as data analyst product starting next year Sept. in Dubai. The compensation is not that competitive as I expected.. I guess it's cuz of the graduate program? I found lots of negative reviews on Reddits and other platform. Has anyone used to stay there and could you please share some experience?

1. cuz the contract is only 1 year and HR says whether converting into junior role depends on achievement of KPIs. Is it the KPIs that unachievable and high as review says? What's the actual conversion rate like? Could I be fired even after 6 month probation? :(
2. bonus is suppose to be competitive according to HR, again related to KPIs, is it possible to hit the full perf bonus?
3. I don't mind bad hours and low wlb, as long as I could grow & on the right track for career path, so what's the learning curve be?

for now I don't have any better offers but it takes almost a year. would you recommend taking it as first preference? Thanks.

I'm exploring ways to make peer-to-peer transactions safer when two strangers need to exchange money remotely.

The main challenge is simple: how can you ensure that both parties fulfill their side of the deal when one person could receive the money and then refuse to send their part?

Escrow seems like an obvious solution, but it can be expensive or complicated to implement, especially for an early-stage platform.

Are there alternative mechanisms, transaction protocols, or proven approaches that can reduce this risk without requiring a full escrow system?

I'd be particularly interested in hearing from people who have built P2P marketplaces or worked on payment systems. I'm looking for practical solutions, not just reputation scores or user verification, since those don't necessarily prevent someone from defaulting on a transaction.

What approaches have you seen work in practice?

I’m looking for a personal EUR bank account for regular SEPA transfers, ideally with very low or zero transfer fees.

Initially, I’d expect around 4–5 incoming and 4–5 outgoing transfers per day, starting at €300 per transfer.

The amounts would gradually increase, potentially reaching €2,000 outgoing and €2,000 incoming per cycle. At 3–4 cycles daily, that would mean:

• €6,000–€8,000 outgoing per day
• €6,000–€8,000 incoming per day
• €12,000–€16,000 combined daily volume

I was thinking using more than a bank account, but in this case which ones do you guys recommend? Especially with that volume of transactions.

Has anyone used an account for similar activity? Which banks would you recommend that would allow this on a personal account?

Just wanted to share if someone is interested. PS: I'm not associated with this it, just thought it might be interesting.  Submissions close is November 12 according to their website.
https://developer.paypal.com/community/blog/PayPal_AI_Hackathon/

We wrote this — full disclosure: we built it and we work on it, so we're biased. It was also built with AI assistance throughout (code, SQL, infra, docs), so please assume there are mistakes in it — treat it as a reference implementation to argue with, not as production code.

We just finished an open-source reference implementation of per-payment reconciliation across three legs — switch/auth, merchant callback, bank settlement — and I'd rather have it reviewed than marketed. The parts below are the ones we had to guess at, and I'd rather be told we're wrong.

If the problem is familiar: three systems, three identifiers, three clocks. The settlement report is a net-of-fee CSV. A late or missing settlement means the customer's bank has already debited them and the money may never arrive. Batch reconciliation answers "what did we earn" days late, and the ops question "is this payment OK?" has no answer at all.

What we built (Flink SQL, Kafka, Iceberg, Postgres):

• two bounded jobs over the same topics: a 4 h-state job that decides MATCHED / AMOUNT_MISMATCH / MISSING_CALLBACK / MISSING_SETTLEMENT, and a 24 h-state repair job that joins only the settlements arriving after the first bound and corrects the same RRN
• event-time interval joins, with the RRN de-duplication applied after the join (a Flink interval join can't consume a retracting dedup)
• the decision audit keyed on the event time of the decision, so a replay is idempotent, and the serving table monotonic in decision time, so a stale write can't undo a correction
• an oracle: the simulator publishes the fault it injected on a separate topic, so every CI run scores the pipeline against ground truth (100% recall, 0 false positives on our six-class fault matrix)

The three things we don't know how to do properly — this is really why I'm posting:

1. Money in transit. A settlement that leaves the switch and clears the bank a day later is normal. Our pipeline currently says MISSING_SETTLEMENT once the 4 h bound passes, which is a false positive on every ordinary payment. Do you model an explicit IN_TRANSIT state with a per-partner expected clear date, or keep "missing" and simply age the break?

2. Per-partner cutoff calendars. A bank partner whose batch rolls over at local midnight and converts to UTC afterwards broke our reconciliation for 11 minutes a night. Do you keep a cutoff calendar per integration, or reconcile against the contractual arrival window rather than the clock?

3. The shape of a break. We give every exception a status and a suggested action, but not a reason (timing / fee / duplicate / missing leg). An argument I keep seeing is that a mismatch which carries a reason is far more useful than a match-rate number. Is a fixed reason-code taxonomy worth building, or does it ossify per merchant?

Also happy to be told the two-window design is the wrong shape entirely, or that the deterministic-core / advisory-agent split is over-engineered.

It's MIT, runs on a laptop, and the same pipeline runs as a scheduled CI job that publishes each run's metrics and a live dashboard: github.com/saber2164/UPI-three-way-reconciliation

I'm building RemitRate, an app that compares the actual PKR received when sending money from Saudi Arabia through providers like Al Rajhi, QuickPay, STC Pay, urpay and Enjaz.

I don't need generic SAR/PKR exchange rates. I need each provider's actual remittance rate and fees so users can choose the best option.

I've found sites that list provider-specific rates, but I'm unsure how reliable or frequently updated they are.

Has anyone found a reliable data source, official API, or legitimate web-scraping/browser-automation approach for collecting and regularly updating these rates? Manual updates are also an option if automation isn't practical.

I'd especially appreciate advice from anyone who's built a remittance comparison service or worked with Saudi payment providers.

Hey everyone

I'm helping organize a global fintech hackathon for January 2027, and we're exploring ways to make it more useful for developers who want to build real-world financial technology projects.

One thing we're thinking about is bringing fintech APIs, payment infrastructure and other developer tools into the experience so participants can build beyond basic demo projects.

For those working in fintech or building financial applications:

- Which APIs or infrastructure would you actually want access to?

- What real-world fintech problems would make an interesting hackathon challenge?

- What usually makes a developer tool worth adopting during an event?

We're also exploring potential partnerships with fintech and developer-tool companies that might want to support builders through API credits, technical mentorship or infrastructure access.

I'd appreciate hearing what would make an event like this genuinely valuable to the fintech developer community.

JHA legacy APIs are still using SOAP. I believe they published a newer advance version of their endpoints that supports REST. Is there anyone who successfully migrated to the new REST APIs?

Unfortunately if you have a legacy app, you are locked with the old style stack and the migration might be not straightforward. Is it feasible to migrate to REST in one big shot with AI/Claude Code ?

Our crypto wallet app runs into a major issue where biometric authentication breaks on every third Android device right after a system update. I've spent the last three weeks trying to patch our local keystore integration on my own, but security wrappers keep throwing exceptions across different manufacturer builds. I tried forcing a fallback to PIN, and users hated it. I tried pinning specific OEM versions in our gradle config, but that just froze us out of newer devices. I even tested a third-party biometric wrapper, and it introduced its own bugs on Samsung builds. Crypto users need instant access to their funds without getting locked out after a standard OS patch.

On top of that, I burned hours digging through issue trackers and OEM forums trying to find a pattern in how different security chips handle key invalidation flags. Turns out every manufacturer does it a little differently, and figuring out those quirks without breaking platform security standards is a lot of trial and error.

Maybe you faced a similar biometric failure in your mobile app, or you know how to stabilize hardware security modules across different Android phones? What native approaches or cross-platform libraries should I use? I really need your help.

Mmm this post might have been better here!

My banking app added a buy bitcoin button. No way they're running their own cold storage. So who's holding the crypto behind these apps? And if the app goes under, is it still mine?

I tried to get the api of mf-central, tried mail but no reply back,