The First 30 Days: How Speqto Actually Onboards a New BFSI Client

Most agencies talk about “seamless onboarding” and then send you a generic questionnaire on day one. We’ve built our first 30 days differently, mostly because we learned the hard way what happens when you skip the boring parts on a fintech project.

A couple of years ago, we started work with a Pune-based NBFC that wanted a loan origination system rebuilt in under four months. We were excited, jumped straight into wireframes in week one, and by week three discovered their existing core banking vendor had API rate limits nobody had mentioned. That cost us almost ten days of rework. Since then, our first 30 days follow a fairly strict rhythm, and it’s saved every project after that from similar surprises.

Days 1-5: Understanding the Business, Not Just the Brief

The first week is not about design mockups or sprint boards. It’s about sitting with the client’s compliance, product, and tech teams separately, because they rarely say the same things when they’re in the same room.

• A call with the founder or CXO to understand what “success” looks like in business terms — is it reducing loan disbursal time from 3 days to 4 hours, or is it passing an upcoming RBI audit?
• A separate session with the compliance/risk team, because in BFSI projects, this is usually where the real constraints live. For a payments client we worked with last year, this single conversation surfaced a PCI-DSS scoping requirement that changed our entire architecture decision before a single line of code was written.
• Reviewing existing documentation — API specs, data flow diagrams, past audit reports if available. If they don’t exist (which is common with smaller NBFCs and lending startups), we document what we can infer and flag the gaps openly.

By day 5, we send a short document called the “Reality Check” — not a proposal, just an honest summary of what we’ve understood, what’s unclear, and what risks we’re already seeing. Clients tell us this is the point they start trusting us, because we’re not pretending to have all the answers yet.

Days 6-15: Scoping, Architecture, and the Uncomfortable Questions

This is where most of the real work of the first month happens. We map out:

• Data residency and storage requirements — a lot of our BFSI clients assume AWS Mumbai region is automatically compliant with RBI’s data localization norms. It’s not automatic; it needs explicit configuration and documentation, and we walk through this line by line.
• Third-party integrations — credit bureaus, KYC providers like DigiLocker or Aadhaar eSign, payment gateways. For a Chennai-based lending platform we worked with, this stage alone took nine days because they were integrating with three different bureau APIs, each with different response formats and SLAs.
• A basic threat model. We don’t wait until pre-launch to think about security in BFSI work — vulnerabilities found in week 25 are far more expensive than ones found in week 2.

By the end of this phase, we share an architecture document and a scope note that explicitly lists what’s in and out. We’ve learned that vague scoping is the single biggest cause of relationship friction later, so we’d rather have an uncomfortable scoping conversation in week two than a defensive one in month three.

Days 16-25: The First Real Sprint

Only now do we start actual build work, usually the highest-risk or highest-uncertainty piece first — not the easiest one. If there’s a legacy core banking integration that everyone’s nervous about, we tackle that early, while there’s still runway to change direction if it doesn’t work.

We run daily 15-minute standups and a longer client-facing sync twice a week. For BFSI clients specifically, we also loop in a dedicated point person for compliance questions, because decisions on data masking, audit logging, or consent flows often can’t wait for the next sprint review.

Days 26-30: The Checkpoint That Isn’t a Demo

Most agencies end month one with a shiny demo. We do that too, but the more important thing we deliver is a written 30-day retrospective — what went as planned, what didn’t, and what we’re adjusting for month two. We send this even when things have gone well, because BFSI stakeholders usually need to report progress upward, and a clear document helps them do that internally.

With the Pune NBFC we mentioned earlier, this retrospective habit is actually what saved the relationship after our rocky start. Instead of hiding the API rate-limit issue, we documented it plainly, showed the revised timeline, and they appreciated the transparency enough to extend the engagement by another year.

Why This Matters

Thirty days isn’t enough time to build much in BFSI software — the stakes and compliance layers are too high for that. But it’s enough time to know whether a partnership is going to work. Our first month is designed to answer that question honestly, for us and for the client, before either side has invested too much to change course easily.