# attpro - The AI collections operating system for Indian lenders > ATTPRO BUSINESS SOLUTIONS PVT LTD is a debt management company operating from 8 cities in west, south and north India, with 325 people on the collections floor and in the field. Its collections business began in 2000. attpro is the company's AI collections operating system: it runs that operation and is licensed to lenders. One borrower record, a visual strategy engine, AI voice in ten Indian languages plus Hinglish, messaging, field operations, payments and a hash-chained evidence ledger, with RBI, DPDP and TRAI constraints enforced by the system rather than by training. Source: https://attpro.collbox.in. Generated from the site's own content modules. Short index: https://attpro.collbox.in/llms.txt ## Company - Legal entity: ATTPRO BUSINESS SOLUTIONS PVT LTD - Collections business founded: 2000 - Promoted by: SFS Allianz Pvt Ltd, Panobiz Business Technologies - People on the floor and in the field: 325 - Cities: Mumbai, Chennai, Cochin, Bangalore, Delhi, Pune, Kolhapur, Goa (stationed teams in Mumbai 145, Chennai 45, Pune 40, Kolhapur 40, Goa 30, Delhi 25) - Cases handled a month: 3.2 lakh (as at 2026, unconfirmed) - Principal under management: ₹696 Cr (unconfirmed) - Retail products worked: Home loans, Mortgages, Affordable housing, Commercial vehicle, Construction equipment, Auto, Unsecured credit lines, Two-wheeler, Business loans, Personal loans, Credit cards, Digital lending, HHT deactivation ### Leadership **Hrishikesh Adwalpalkar** - Director, Collections and recovery. About 30 years in debt management. Built the collections business from 2000 on a single competency: receivables on overdue instalments, secured and unsecured. Formerly: TCFC (Centurion Bank), Escorts Finance. Answers for: Client delivery across every stationed site and the field network; Bucket-wise recovery strategy and the escalation ladder; Code-of-conduct audits and RBI guideline adherence; Agency governance where a client's own agencies sit on the platform. Ask about: What actually moves a 90+ bucket; Running field recovery inside RBI guidelines; Why the floor uses its own software; Agency consolidation for a lender. **SK Viswanath** - Director, Retail finance. Two decades in senior and top management in retail finance. Former VP and National Head for personal and gold loans at HDFC Bank. Formerly: HDFC Bank. Answers for: Lender relationships and portfolio reviews with client collections heads; Settlement and hardship policy on the managed-recovery book; Product input on reporting, forecasts and credit-side analytics; Board oversight of risk and financial controls. Ask about: What a bank's collections head actually measures; Settlement waterfalls that protect the book; Gold and personal-loan delinquency; Vendor governance from the lender's chair. **Rajagopal KA** - Director, Distribution and growth. Two decades in business development and distribution across BFSI. Former VP and National Sales Manager at HDFC ERGO. Formerly: HDFC ERGO. Answers for: New geographies and the retail-finance sales bench; Staffing and payroll services for client-embedded teams; New lender relationships and engagement models; The partner network for agencies and ARCs on the platform. Ask about: Standing up a team in a new city in weeks; Distribution economics in BFSI; Embedding staff inside a lender; How agencies and ARCs adopt the platform. **Amit Singh** - Director & CTO, Product and engineering. Architect and builder of the ATTPRO collections operating system. Founder and CEO of AcmaCorp Solutions Pvt. Ltd., AcmaTel Communications Pvt. Ltd. and MediSuggest Services India Pvt. Ltd., and CTO at AcmaSoft Technologies. Answers for product, engineering and platform security. Formerly: PCS Technology Ltd., Omnitech Info Solutions Ltd., CMS Computers Ltd.. Answers for: Product and engineering: roadmap, releases, the changelog; Platform architecture: voice, flows, channels, field, payments, evidence; Security and data protection: DPDP, audit trail, tenant isolation, vendor questionnaires; Integrations with lender core systems, telephony, messaging and payment rails; Technology direction across the group companies he leads. Ask about: Voice AI that works in Indic languages; Designing a flow engine for collections; DPDP and data residency for a lender; Why BYO credentials and empty-by-default; Integrating with an LMS or core banking system; The IT challenges specific to debt collection; Global talent and continuous skill development; Building a corporate culture on purpose. ### Customers **Live under ATTPRO**: Reliance ARC, Navi Finserv, Authum Investments & Infrastructure, ARCL, Arth, Chola. Asset reconstruction companies, NBFCs and lenders contracted directly with ATTPRO Business Solutions. **Collected for by the SFS group**: HDFC Bank, Yes Bank, Kotak, Federal Bank, AU Small Finance Bank, Bank of Baroda, Saraswat Bank, HDFC Home Loans, SMFG Grihashakti, Bajaj Finserv, Shriram Finance, DMI Finance, Saison Card, Navi Finserv, FlexiLoans, Branch, Olyv, Fiserv. Private banks, NBFCs, fintechs, a cooperative bank, a PSU bank and a payment processor, under the promoter entity. ### Code of conduct - DRA-certified employees: Every caller and field officer holds the IIBF Debt Recovery Agent certification before they work an account. - Police clearance before hiring: Background screening with a mandatory Police Clearance Certificate, for the floor and the field. - Training for the lowest escalation rate: Outbound call training is measured on complaints avoided, not calls made. - Timelines enforced in software: Calling and field-visit windows are gates in the dialer and the FOS app, not lines in a policy document. - Periodic refresher training: Every employee re-trains on RBI conduct expectations on a fixed cycle. - Internal audit controls: Conduct, recordings and dispositions are sampled and audited internally every cycle. ## Managed recovery services **Telecalling** - A calling floor that runs on the platform it sells. Auto-dialer calling over GSM gateways, with a recording on every seat. Dispositions, promises and QA go into the same borrower record the digital and field work writes to. DRA-certified callers, background-screened before hiring Auto-dialer and soft-calling over GSM gateways Recording on every seat; QA sampling on every cycle Calling windows enforced in software, not in training **Field presence** - Doorstep teams in six cities, reporting into one record. Stationed field teams across Maharashtra, Goa, Tamil Nadu and Delhi. Visits are allocated from the flow, captured on the FOS app with geo-tag and time, and returned as evidence. Stationed teams in Mumbai, Pune, Kolhapur, Goa, Chennai and Delhi Allocation, directions and scripts on the officer's phone Geo-tagged, time-stamped visit records that stand up in a dispute Field-visit timelines enforced in software **Digital outreach** - Segmentation first, then the right channel on the right cohort. SMS, WhatsApp, RCS, email, IVR and AI voice calling on the cohorts that will answer them. The cheap channels carry the volume; people and field see only what survives digital. SMS, WhatsApp, RCS, email letters, IVR and AI voice TRAI DLT-bound templates; consent and DNC honoured across channels Every delivery, read and reply signal feeds the next step Self-serve pay links so a borrower can settle at midnight **Every retail asset class** - Secured and unsecured, every bucket. Twenty-five years across the retail book: the strategy for a two-wheeler loan in bucket two is not the strategy for a mortgage in bucket four, and the floor knows the difference. Home loans, mortgages and affordable housing Commercial vehicle, construction equipment and auto Personal loans, business loans, credit cards and digital lending Two-wheeler, unsecured credit lines and HHT deactivation ### Engagement models **Managed recovery**: You allocate the portfolio. We run telecalling, digital and field on our platform, with our people. Commercials on recovery. You: Allocate the book and read the reports. We: Run every channel, every bucket, every city. Best for: Buckets you would rather not staff. **Platform licence**: You run your own collections team on the ATTPRO platform, in your own tenant, with your own carrier and payment credentials. You: Run your team on the software. We: Run the platform, onboarding and support. Best for: In-house teams that need the software. **Hybrid**: Your team on early buckets, ours on the hard ones, both in one tenant with a single reporting line. You: Work the early buckets in-house. We: Take the deep buckets and the field. Best for: A phased transition, or a book with two shapes. ## Platform ### Architecture - Data in: Lender LMS export, Upload wizard: map, preflight, commit - Decisioning: Master data, Allocation engine, Campaign windows, Flow: the playbook - Contact: AI voice agent, Human telecaller, SMS, WhatsApp, email, Field officer, portal - Response: Disposition, Payment or PTP, Signals: DLR, read, keypress, visit - Evidence: Audit log, hash-chained, QA sampling, Recordings, transcripts, Archive, purge, legal hold Dispositions and signals from the response band feed back into decisioning; that feedback arrow is the platform. ### Flow engine - A node that acts never blocks: A call, a visit or a message parks the run and resumes when the webhook, the lifecycle event or the timeout comes back. A lakh runs cost a lakh rows, not a lakh threads. - Waiting guard: A run only resumes if it is actually waiting, so a duplicate webhook cannot double-advance it. - Prefix guard: A late delivery receipt cannot resume a run that has already moved on to a different wait. - comm.* - Contact the borrower on a channel - logic.* - Branch, gate, split, join - wait.* - Park until a signal arrives or the timer expires - data.* - Enrich, score, capture a form, call a webhook - alloc.* - Re-allocate, suppress, build a cohort ### Day one - 10 Indian languages plus Hinglish: Hindi, Tamil, Telugu, Marathi, Bengali and more - and the Hinglish borrowers actually speak - natively, not translated. - Sub-second voice: Real-time, interruptible conversation that does not feel like an IVR menu. - True omnichannel: Voice, WhatsApp, SMS, RCS, email, self-serve and field on one journey and one record. - Compliance by design: RBI, DPDP and TRAI rules enforced by the system on every single touch. - Self-serve, one-tap pay: Borrowers resolve on their own terms, at any hour, in a couple of taps. - Field and legal, one journey: Doorstep visits and legal steps flow from the same automation, fully tracked. - Live analytics and QA: Every call, promise and payment measured, with automatic quality sampling. - One record per borrower: Whichever channel touched them, and whoever asks for the evidence. ### AI voice (https://attpro.collbox.in/platform/voice) **A voice agent that holds the conversation, not a script** attpro's voice agents speak ten Indian languages plus Hinglish, listen through interruptions, and carry seventeen in-call tools - so a call ends in a promise, a payment link, a callback, or a clean handoff to a human, never in a dead end. - Live, interruptible conversation: Barge-in and turn-taking tuned for Indian speech patterns. The borrower can talk over the agent and the agent adjusts, the way a good telecaller does. - Seventeen in-call tools: Record a promise to pay, send a payment link, schedule a callback, mark do-not-call, log a dispute, escalate to a supervisor, end the call gracefully - each one writes a real record, not a note. - Answering machine detection: Voicemail is detected, a compliant message is dropped, and the flow moves on. No agent minutes burned on beeps. - Warm transfer with context: When a call needs a human, the telecaller receives the live transcript, the account state and the conversation so far. The borrower never repeats themselves. - Per-agent persona and prompt: Each agent has a name, a register, a language set and a system prompt you control - firm, kind, formal, colloquial. Audition changes on a test call before they go live. - Gated before it dials: Calling window, concurrency cap and do-not-call are checked before the call is placed over the SIP trunk. Recording disclosure is enforced, not optional. - Scored after it hangs up: Summary, sentiment, auto-disposition, QA score and PII redaction are written to the account the moment the call ends. - A realism layer, off by default: Backchannel fillers, a pronunciation dictionary, boosted keywords, ambience, sentiment-adaptive delivery and cross-call borrower memory - switched on per agent when it earns its place. You control: Calling windows per campaign, enforced in IST; Concurrency caps per agent and per tenant; Language set and voice per agent; Which tools each agent may use; Retry ladders and answer-machine policy. It produces: Full recording and word-level transcript per call; Disposition with confidence, written to the account; Sentiment and compliance annotations; QA samples routed for human review. How it runs: The flow places the call - A comm node fires for one borrower inside the calling window, under the concurrency cap, with the agent, language and tools that node allows. Do-not-call and consent are checked before the trunk is touched. The agent holds the conversation - It listens through interruptions, uses the account facts it was given, and reaches for a tool when the borrower commits: a promise, a payment link, a callback, a dispute, a handoff. The account is written, the flow moves - Recording, transcript, disposition, sentiment and QA score land on the account within seconds of hangup. The disposition picks the next branch; nobody re-keys anything. Operating loop: Gate - Calling window, concurrency cap, consent and do-not-call are checked before the trunk is touched. Speak - The agent opens in the borrower's language, identifies the lender and discloses recording. Listen - Barge-in and turn-taking tuned for Indian speech. The borrower can talk over it. Act - A tool fires mid-call: a promise with a date, a payment link, a callback, a dispute, a handoff. File - Recording, transcript, disposition, sentiment and QA score land on the account at hangup. Q: Which languages does the agent actually speak? A: Ten Indian languages plus Hinglish, with the language set chosen per agent. It can switch mid-call when the borrower does, if you allow it, and the switch is logged. Q: What happens when the borrower asks for a human? A: The agent warm-transfers to a telecaller or a queue you name in the flow, with the live transcript and account state on the caller's screen. The borrower does not repeat themselves. Q: Do we bring our own telephony? A: Yes. The platform dials over your Exotel account and your DIDs, so caller ID, recording retention and telecom compliance stay under your name and your contracts. Q: How is a bad call caught? A: Every call is scored after hangup and a QA sample is routed for human review. Compliance annotations flag disclosure misses, tone and prohibited phrases; a supervisor can pull an agent from the floor in one click. ### Messaging (https://attpro.collbox.in/platform/messaging) **Messages that report back, not broadcasts into the dark** SMS, WhatsApp, RCS and email run from the same flow as every other channel. Delivery, read and reply signals come back into the engine and decide the next step for that one borrower. - Four channels, one strategy: A flow node sends on the channel you chose; the borrower's response - or silence - picks the branch. No separate blast tool with its own logic. - DLT template binding: SMS templates are bound to TRAI DLT registrations. An unregistered template cannot be dispatched. - Signals feed the flow: Delivered, read, replied, bounced, opted out - each signal resumes the waiting flow at the branch you drew for it. - Per-channel cooldowns: Contact caps per channel and per day protect borrowers from pile-on and you from complaints. You control: Template library with variable binding; Channel priority and fallback order; Cooldowns and frequency caps; Opt-out handling per channel. It produces: Per-message delivery and read receipts; A touch record on the borrower timeline; Channel performance analytics by cohort. How it runs: A node sends on the channel you chose - SMS, WhatsApp, RCS or email, from a template bound to its DLT or WhatsApp registration, with the borrower's variables filled from the account. The engine waits for the signal - Delivered, read, replied, bounced, opted out. The flow parks on the borrower and resumes on the branch you drew for whatever comes back, or on the timeout you set. Silence is a decision too - No reply in seventy-two hours is a branch, not a dead end: escalate the channel, place a call, or hold, exactly as the strategy says. Operating loop: Compose - From a registered template in the borrower's language, with the amount and the link already in it. Gate - Quiet hours, frequency caps counted across channels, and opt-out state, all checked at dispatch. Send - SMS, WhatsApp, RCS or email, through your own provider credentials. Hear back - Delivered, read, replied, clicked, bounced. Four different states, not one. Branch - Each signal resumes the parked flow on its own branch, including the silence. Q: Is DLT registration enforced? A: An SMS template that is not bound to a registered DLT template ID cannot be dispatched. The same binding applies to WhatsApp templates and their approval state. Q: Can a borrower reply and reach a person? A: Yes. Replies land on the borrower timeline and can route to a queue; a keyword or a sentiment can also pull the account into a human's list. Q: Whose messaging account is used? A: Yours. Credentials for Helo.ai, SendGrid and WhatsApp Business sit encrypted in your tenant and never leave it. Costs land on your invoices at your negotiated rates. ### Flow builder (https://attpro.collbox.in/platform/flows) **Draw the strategy once. The engine runs it a lakh times.** A recovery strategy is a graph: contact, wait for what happens, branch on the outcome, escalate. attpro's flow builder makes the graph visible, validates it before publish, and executes it per borrower, continuously. - Visual canvas: Nodes for every channel and decision, edges labelled with real outcomes: answered, promised, paid, no response in 72 hours. The whole strategy on one screen. - Branch-complete validation: A flow cannot publish unless every outcome of every node has a branch. The engine never improvises when a borrower does something you did not draw. - Park and resume: Flows wait on the real world - a payment landing, a visit completing, a message being read - and resume the moment it happens, or take the timeout branch you chose. - Versioning and publish gates: Edit safely while the published version keeps running. Publishing is explicit, validated and audited. - Five node families: comm.* contacts the borrower, logic.* branches and gates, wait.* parks on a signal or a timer, data.* enriches and scores, alloc.* re-allocates and suppresses. Everything the floor does is one of those. - Generate it from plain English: Describe the ladder and the composer draws it; hand-edit on the canvas from there. Non-technical operators build these. You control: Per-campaign activation windows and days; Timeout branches on every wait; A/B splits on any edge; Active and inactive runtime toggle. It produces: A run record per borrower with every node visited; Branch analytics: where accounts cure, stall or escalate; An auditable trace of why each contact happened. How it runs: Draw the strategy once - Segments, channels, waits, conditions and handoffs on a canvas your collections head can read. The validator refuses to publish a flow with an unhandled branch. Allocate a cohort - A campaign picks the accounts by DPD, product, ticket and risk tier and enrols them. Each borrower gets their own run, starting at the node the rules say. It runs every day, on every account - The engine advances each run on real signals: a delivered message, an answered call, a payment, a field visit, a promise date arriving. You watch the dashboards, not the queue. Operating loop: Draw - Buckets, channels, waits and escalation on a canvas, with branch labels on every edge. Validate - Publishing is refused while any documented branch is unhandled. The graph is the whole policy. Dispatch - One run per borrower, gated on the campaign window and the batch it belongs to. Park - The run waits on a real signal: a receipt, a disposition, a promise date, a payment. Resume - The signal arrives, the branch is stamped, and the next node is dispatched. Q: Can we change a live flow? A: You edit a draft, the validator checks it, you publish. Running borrowers continue on the version they started on unless you choose to migrate them; a restart is one action on the account. Q: How do timeouts and quiet hours interact? A: A wait node can carry a named timeout branch. Every outbound node checks the campaign's active hours and the tenant's quiet hours in IST before it fires, and defers rather than skips. Q: Do we start from a blank canvas? A: No. A template library ships with bucket-wise strategies the ATTPRO floor runs, and a description-to-flow composer drafts a first version from a paragraph. Both are starting points, not constraints. ### Field operations (https://attpro.collbox.in/platform/field) **Field visits that end as data, not diary entries** The FOS app puts the day's allocations, directions and scripts on the officer's phone, works without signal, and returns geo-tagged visit records the flow can act on. - Allocation on the phone: Each officer sees their accounts, addresses and history. Supervisors see coverage and outcomes. - Offline first: Visits, PTPs and receipts are captured without network and sync when signal returns. Field work does not wait for 4G. - Geo-tagged evidence: Every visit carries location, time and the captured outcome - evidence that stands up in a dispute. - The flow reacts: A completed visit is a signal like any other: the flow branches on visited, paid, promised, or not found. - The FOS App by ATTPRO: Android and iOS from one codebase, distributed privately to your officers. The whole day on one phone, with or without signal - see the app page for the officer's view. You control: Beat planning and allocation rules; Visit outcome taxonomy; Receipt formats and numbering. It produces: Geo-tagged visit records; Field-collected PTPs and payments; Officer productivity analytics. How it runs: The flow dispatches a visit - A field node allocates the borrower to an officer by beat and capacity, with the script, the address and the account history already on the phone. The officer works offline - Visits, receipts, photographs and promises are captured without signal and sync when it returns. The queue never blocks on a lift or a basement. The visit comes back as evidence - Geo-tag, time, outcome and receipt land on the account; the flow branches on visited, paid, promised or not found. A dispute later has a record to answer it. Operating loop: Allocate - Cases go out by beat, capacity and the strategy that put them there. Plan - The officer opens the day's list with addresses, history and the script for each visit. Visit - Captured on the doorstep, offline if the network is not there. Evidence - Location, time and outcome recorded together, so the record stands up in a dispute. Sync - The disposition reaches the flow the moment the phone finds a signal. Q: Which phones does the FOS app run on? A: Android and iOS from one codebase, distributed privately to your officers. It is built for the budget Android phones a field team actually carries. Q: How are officers and beats managed? A: Beat planning and allocation rules sit in the admin app; supervisors see coverage, outcomes and productivity per officer, and can re-route a beat during the day. Q: Can receipts be trusted? A: Receipt numbering is controlled by the platform, every receipt carries the officer, the location and the time, and the amount reconciles against the payment rail the same day. ### Payments (https://attpro.collbox.in/platform/payments) **The shortest path from promise to money in the account** Payment links, UPI and NACH, promises tracked to the day, and a self-service portal where a borrower can settle at midnight without speaking to anyone. - Links in every channel: The voice agent, a WhatsApp message or a field officer can issue the same payment link, tied to the account and reconciled automatically. - PTP tracking: Promises have dates. Kept promises close the loop; broken ones re-enter the flow on the branch you drew for exactly that. - Self-service portal: A borrower-facing page with the outstanding amount, payment options and receipts - no app install, no login friction. - Reconciliation: Razorpay and Cashfree callbacks post payments to the account in near real time. The ledger, not a spreadsheet, is the source of truth. You control: Payment partner and methods per tenant; Settlement offer rules and approval chains; Receipt and acknowledgement templates. It produces: Payment records reconciled to accounts; PTP kept / broken analytics; Cure attribution by channel and flow branch. How it runs: The right rail for the moment - A payment link in the call, a UPI intent in a message, a NACH mandate for a plan, a portal for the borrower who prefers to act alone. All from the same flow. The payment lands on the account - Razorpay or Cashfree webhooks post the payment against the loan in seconds. Promises are matched, partials are recognised, the balance is right. The flow reacts, the ledger keeps the story - A payment stops the escalation. A missed promise restarts it. Every rupee has a source, a time and a touch that earned it, ready for reconciliation. Operating loop: Agree - A promise is captured as a date and an amount, in the conversation, as fields. Send - The payment link goes out while the call is still live, not after it. Remind - The day before and the morning of, against the borrower's own commitment. Collect - Links, UPI, NACH mandates and the self-service portal, on your own gateway keys. Reconcile - The receipt matches back to the loan and the promise, so nobody chases paid money. Q: Whose payment gateway is it? A: Yours. Your Razorpay or Cashfree credentials, your settlement account, your rates. The platform creates links and mandates on your behalf and reads the webhooks. Q: How are promises to pay tracked? A: A promise is a dated record on the account. The engine watches the date: a payment by then keeps the promise, a miss branches the flow and marks the promise broken for the dashboards. Q: What about settlements and hardship? A: Settlement offers and hardship plans are records with an approver, a validity and a schedule. The workflows for negotiated restructures are on the roadmap and are not yet in the product. ### Analytics (https://attpro.collbox.in/platform/analytics) **The book, explained - not another export to Excel** Operations dashboards, AI cohort intelligence, recovery forecasts and agent performance, computed on the live book and rendered in the units Indian lending actually uses. - Operations dashboard: Portfolio health, contact funnels, channel performance, batch lifecycle - filtered by campaign, DPD bucket, status and risk tier. - AI intelligence: Risk distribution, predictive cures, settlement opportunity, contact-time heatmaps and risk migration - cohort views that tell you where to spend the next rupee of effort. - Recovery forecast: Expected recovery by cohort with the assumptions visible, so risk and finance argue about inputs, not arithmetic. - Agent and campaign performance: Human and AI agents on the same yardstick: connects, promises, cures, complaint rates. You control: Saved views and scheduled reports; Campaign, DPD, status and risk filters everywhere; Export when you need it, not as the default workflow. It produces: Daily operating picture for the collections head; Cohort evidence for strategy changes; Board-ready recovery and cost curves. How it runs: Everything is already an event - Every call, message, visit, promise and payment is written with the borrower, the campaign, the node and the time. There is no export project before the first chart. Dashboards read the same ledger - Resolution by bucket, cost to collect, promise-kept rate, channel performance, agent productivity and roll rates, filtered by campaign, product and date, in IST. The numbers change the strategy - A cohort that responds to WhatsApp at 7pm gets that branch; a script that loses in Tamil gets rewritten. Analytics feeds the flow builder, not a slide deck. Operating loop: Capture - Every contact, disposition, promise and payment is written as it happens. Cohort - Cut by bucket, product, vintage, campaign, channel and caller. Compare - Roll rate and cure rate on a fixed cohort, not a moving denominator. Forecast - Expected recovery on the live book, with the assumptions visible. Act - The finding changes a flow, a cap or an allocation rule, not a slide. Q: Can we pivot the raw data ourselves? A: Yes. A browser pivot over the account and touch data, saved views, and scheduled reports by email. For deeper work, exports and a read API. Q: Is there borrower-level intelligence? A: Each account carries a risk tier, a propensity estimate, a best channel and time, and a conversation prep for the caller. Cohort views aggregate the same signals. Q: How fresh are the dashboards? A: Operational views read live data. Heavier aggregates refresh on a schedule you can see on the page, and every figure states its as-at time. ### Compliance (https://attpro.collbox.in/platform/compliance) **Compliance as physics, not policy** Quiet hours, consent, contact caps and evidence are enforced by the engine itself. A call that would breach the rules is not flagged afterwards - it is never placed. - Quiet hours in the dialer: Calling windows are enforced in IST at dispatch time, per campaign. Outside the window, the call does not exist. - Consent and DNC ledger: Do-not-call is honoured across every channel, tenant-wide and platform-wide. Consent state is a record, not a memo. - Evidence by default: Every contact, disposition and payment writes an audit row. Recordings and transcripts retain on the schedule you set. - Tamper-evident audit: Audit logs are anchored with a Merkle chain, so evidence produced in a dispute can be shown untouched. - Data lifecycle: Archive, purge and legal hold per DPDP - retention that a data protection officer can sign. - PII redaction and disclosure: Transcripts carry PII redaction; recording disclosure is played on every call by the engine, not by the agent remembering to. You control: Calling windows and quiet hours per campaign; Frequency caps per channel and per borrower; Retention schedules for recordings and records; Legal hold overrides with audit. It produces: A complete, ordered evidence trail per account; Consent and DNC state with history; Regulator-ready extracts on demand. How it runs: The rules are configuration - Quiet hours, contact caps per channel and per day, consent state, do-not-call, disclosure scripts and retention schedules are settings the engine reads, not a training deck. Every touch is checked before it fires - An outbound node that would breach a window, a cap or a DNC flag defers or branches. The check is logged either way, so you can show what was refused and why. The evidence writes itself - A hash-chained audit log, recordings with disclosure markers, consent history and retention actions. An RBI or DPDP question has an answer you can export. Operating loop: Configure - Windows in IST, caps per day and week, consent and do-not-call state. Enforce - Checked at dispatch, not at design time, so a delayed queue cannot create a breach. Record - Each contact carries the rule that allowed it, the campaign and the outcome. Chain - Audit rows are append-only and hashed, so alteration is detectable rather than deniable. Produce - One borrower, twelve months, with times and outcomes, without a ticket to engineering. Q: Which regulations does this map to? A: RBI's Fair Practices Code and outsourcing guidelines for collections conduct, TRAI DLT for SMS, and the DPDP Act for personal data. The compliance hub lists each control against each clause. Q: Can a borrower see and exercise their rights? A: A borrower portal shows what is held and lets them raise a grievance, request a callback or opt out of a channel. Grievance handling has its own SLA clock and escalation. Q: How is data retention handled? A: Retention schedules per record type, executed by the platform on schedule and logged. Recordings and transcripts age out on the policy you set, with legal holds where a dispute is open. ### Channels (https://attpro.collbox.in/platform/channels) - Messaging and self-serve (very low cost): SMS, WhatsApp, RCS, Email, Lender-app nudge, Self-serve pay link - Voice (low cost): AI voice call, Voice broadcast, Voicemail drop - Human and field (high cost): Warm transfer to agent, Live agent queue, Field visit, Field officer alert - Legal and recovery (highest cost): Formal notice, Settlement offer, Repossession, Asset auction, SARFAESI notice, Legal filing, Write-off review - very low cost tier - Digital and self-serve: SMS, WhatsApp, RCS, Email, App nudge, Pay link, Voice broadcast, Voicemail - low cost tier - Automated voice and notices: AI voice call, Formal notice, Settlement offer - high cost tier - Live human agents: Live agent queue, Warm transfer - highest cost tier - Field and legal: Field visit, Repossession, Asset auction, SARFAESI, Legal filing ### Escalation ladder (https://attpro.collbox.in/platform/strategy) - Tier 0 Remind (Pre-due): Reach the borrower before the instalment is late. Channels: SMS, WhatsApp, Pay link - Tier 1 Nudge (Day 1 to 3): Repeat on the channel the borrower reacts to. Channels: WhatsApp, SMS, Voice broadcast, App nudge - Tier 2 Negotiate (Day 4 to 10): The AI agent negotiates and captures a promise to pay. Channels: AI voice call, Email - Tier 3 Escalate (Day 11 to 20): A firmer call, then a human agent with full context. Channels: AI voice call, Live agent, Warm transfer, Formal notice - Tier 4 Recover (Day 21 to 30): Doorstep visit, then the recovery track. Channels: Field visit, Settlement, Legal ## Solutions by lender type ### NBFCs (https://attpro.collbox.in/solutions/nbfc) **Run a five-lakh-account book with the team you already have** An NBFC book grows faster than a telecalling floor can. Early buckets get blasted, deep buckets get ignored, and the strategy that works lives in one manager's head. attpro turns that strategy into a flow the engine runs on every account, every day - and your people handle only the conversations that need a human. - Early-bucket automation: Pre-due and 1-30 DPD run on voice AI and messaging with no human minutes. Your callers start the day where judgement matters. - Strategy per segment: Different flows for different products, tickets and risk tiers - salaried personal loans do not get the two-wheeler treatment. - RBI posture built in: Fair Practices Code conduct, quiet hours, contact caps and a complete evidence trail, enforced by the engine rather than the training calendar. Reported metrics: Resolution rate by bucket; Cost to collect per account; Promise-kept rate; Roll-forward and flow rates. Integration: Nightly LMS export over SFTP is enough to start. REST and webhooks when you want same-day state. Named customers of this type: Navi Finserv, Chola, Bajaj Finserv, Shriram Finance, DMI Finance, Authum. First ninety days: Weeks 1 to 2: one cohort on the platform - A nightly LMS export, a mapped upload and one bucket enrolled on a template flow. Your callers keep working; the engine takes pre-due and early DPD. Weeks 3 to 6: the strategy becomes yours - Scripts, languages, channel order and settlement rules tuned on the numbers from the first cohort. The second and third products come on book. Weeks 7 to 13: the floor changes shape - Human minutes move to the buckets that need judgement. Cost to collect and promise-kept rate are on the dashboard your CFO reads. Q: Do we need to change our LMS? A: No. A nightly extract over SFTP with a saved column mapping is enough to run the book. REST and webhooks come later, when you want same-day state. Q: Can our existing agencies work inside it? A: Yes. Agency users get role-scoped access to the accounts allocated to them, work the same flows and leave the same evidence, so agency performance becomes a dashboard rather than a monthly argument. Q: What does a pilot cost? A: Pricing is per active account per month with usage on your own provider accounts. A pilot on one cohort is scoped and priced on the pricing page's terms, with no platform build fee. ### Banks (https://attpro.collbox.in/solutions/banks) **Bank-grade evidence with fintech-grade contact rates** A bank's collections problem is rarely reach - it is proving that every contact was compliant, and coordinating agencies, in-house teams and legal without losing the thread. attpro is the system of record across all of them. - Evidence-first operation: Tamper-evident audit, recordings, consent state and retention schedules - built for the audit you will eventually face. - Multi-team orchestration: In-house callers, field teams and DRA-certified agency staff work the same flows with role-scoped access. - Data residency: Deployment in India, schema-level tenant isolation, and your own provider credentials for telephony and messaging. Reported metrics: NPA slippage prevented; Audit findings per cycle; Agency performance variance; Resolution by vintage. Integration: Core-banking extracts over SFTP, with per-field mapping and preflight validation before anything touches the book. Named customers of this type: HDFC Bank, Kotak, Yes Bank, Federal Bank, AU Small Finance Bank, Bank of Baroda, Saraswat Bank. First ninety days: Weeks 1 to 3: information security first - The questionnaire, the data-residency statement, the BYO-credential model and the audit-log design go to your infosec team before any data does. Weeks 4 to 8: one product, all teams - In-house callers, one agency and the field team work a single product's book on the platform, each with their own role and their own evidence trail. Weeks 9 to 13: the audit pack - Recordings, disclosures, consent state, contact caps and retention actions for the pilot period, exported as your internal audit would ask for them. Q: Where does the data live? A: In India, in your own tenant schema, with your provider credentials encrypted at rest. The trust center carries the current hosting statement and sub-processor list. Q: Can we run it for one region or product first? A: Yes. Tenants, campaigns and role scopes let a single product or circle run on the platform while the rest of the book stays where it is. Q: How do agencies and legal see the same thread? A: Every touch, from a WhatsApp to a legal notice, sits on one borrower timeline with the actor and the time. Legal and agency users see the slice their role allows, on the same record. ### Fintech lenders (https://attpro.collbox.in/solutions/fintech) **Collections that move at the speed you underwrite** Digital lenders approve in minutes and then collect with phone banks. Small tickets cannot carry human calling costs. attpro makes the first five contacts fully automatic and reserves people for the accounts that earn them. - Unit economics that work at small ticket: Voice AI and messaging cost a fraction of a telecaller minute, so a Rs 8,000 account can still be worked properly. - API-first: REST and webhooks both directions: push disbursals in, get dispositions and payments out, in near real time. - Experimentation built in: A/B branches inside flows - test a script, a channel order or a settlement offer on a cohort, read the result in the dashboard. Reported metrics: Cost to collect per account; D0-D30 cure rate; Contact-to-promise conversion; Complaint rate. Integration: REST APIs with webhooks; SFTP if your LMS prefers files. Payment callbacks from Razorpay and Cashfree. Named customers of this type: Navi Finserv, FlexiLoans, Branch, Olyv, Saison Card. First ninety days: Weeks 1 to 2: API-first onboarding - Disbursals in over REST, dispositions and payments out over webhooks. A cohort of small-ticket accounts runs fully automatic from day one. Weeks 3 to 6: experiments, not opinions - A/B branches on script, channel order and offer, read in the dashboard by cohort. The winning branch becomes the default. Weeks 7 to 13: humans where they earn it - Only accounts that cross the risk threshold reach a person. Cost per resolved account and roll rates are the numbers the board sees. Q: How fast can we integrate? A: The REST API and webhooks are documented on the developers page; a team with an LMS event stream is usually live on a cohort within two weeks. Q: Does small ticket really pay? A: Voice AI and messaging cost a fraction of a telecaller minute, so an eight-thousand-rupee account is worked on every channel, in the borrower's language, at the right hour. The ROI page runs your numbers. Q: Can we keep our own gateway and telephony? A: Yes, and you should. Your Razorpay or Cashfree, your Exotel, your messaging accounts. The platform orchestrates; your contracts and rates stay yours. ### ARCs (https://attpro.collbox.in/solutions/arc) **Acquired books, worked systematically from day one** An acquired portfolio arrives as files of unknown quality, and value decays while it is being understood. attpro's upload pipeline maps, validates and enrolls a book in days, then works every account on a strategy instead of a triage spreadsheet. - Fast onboarding of messy books: Column mapping, preflight validation and staged commits handle files that were never meant to be exported. - Alternate MetaData in the flow: Unreachable accounts route automatically to trace, and re-enter contact flows when new coordinates land. - Settlement machinery: Offer ladders, approval chains and documented settlements - the ARC workflow, not a retrofit. Reported metrics: Recovery against acquisition value; Traceable-contact rate; Settlement conversion; Cost per resolved account. Integration: File-based onboarding first; APIs when the servicer relationship matures. Named customers of this type: Reliance ARC, ARCL, Arth. First ninety days: Weeks 1 to 3: a portfolio, mapped - Acquired books arrive in the seller's format. Saved mappings, preflight validation and cross-loan grouping turn them into one clean master with a customer view. Weeks 4 to 8: trace, contact, offer - Alternate MetaData on stale contacts, outreach across channels, and settlement offers with an approver and a validity window, all recorded on the account. Weeks 9 to 13: recovery by vintage - Resolution and collections by acquisition tranche, with the evidence a trustee or an investor asks for. Q: Can it handle books from many sellers? A: Yes. Each upload keeps its saved mapping, and accounts from different sellers for the same customer are grouped so one conversation covers all of them. Q: Is Alternate MetaData built in? A: An Alternate MetaData node calls the provider on your credentials, and the flow branches on results found, none found or failed. Results land on the account with their source. Q: How are settlements governed? A: Offers carry an approver, a floor, a validity and a schedule; acceptance and payment are recorded against the offer. Full restructure workflows are on the roadmap. ### Recovery agencies (https://attpro.collbox.in/solutions/agencies) **Show your lenders a control room, not a call log** Agencies win mandates on results and lose them on reporting. attpro was built by one - a 325-seat floor across six cities - and gives every seat a disciplined queue, every lender a clean report, and the owner one screen for productivity across clients. - Per-client separation: Each mandate is its own campaign with its own flows, scripts and reports - no cross-contamination. - Agent productivity: Queues, dispositions, break tracking and QA sampling - the floor runs on the system, not on supervision alone. - Lender-grade evidence: Recordings, transcripts and audit trails that make your compliance answer easy in every review. Reported metrics: Collections per seat per day; Mandate retention; QA pass rate; Report turnaround time. Integration: Works standalone with file uploads from each lender; APIs where a lender offers them. First ninety days: Weeks 1 to 2: your floor on the platform - Callers, supervisors and field officers onboarded with roles, dispositions and scripts. One client's allocation runs end to end with the evidence it expects. Weeks 3 to 6: every client, one system - Each client's book is a campaign with its own rules, windows and reports. Your people work one queue; each client sees only their own data. Weeks 7 to 13: the report that wins renewals - Contact rates, resolution, conduct scores and evidence per client, ready before the monthly review, in the client's format. Q: Can we run several lenders' books separately? A: Yes. Campaign-level scoping keeps each client's data, rules and reporting apart while your team works from one console. Q: Do our telecallers need retraining? A: The caller console shows the account, the script, the conversation prep and the disposition list in one screen. Most callers are productive on the first day; supervisors get live monitoring and break management. Q: How does this help us with DRA and conduct audits? A: Every call is recorded with its disclosure, every visit is geo-tagged, and conduct scoring runs on every conversation. A lender's audit becomes an export, not a scramble. ## Pricing - Per active account, per month: The base metre is the number of accounts actually under collection in the month - not licences, not seats. A quiet book costs less than a busy one. - Usage at cost, through your own keys: Telephony, messaging and AI providers connect with your credentials. You pay those vendors their price, with no margin stacked on top by us. - No per-seat fees: Add supervisors, QA reviewers and field officers freely. We charge for the book being worked, not for the people watching it. **Starter** - First automation on a focused book. Includes: Messaging and OBD channels; Flow builder with validation; Borrower 360 and dispositions; Payments and self-service portal; Operations dashboard; Email support. **Growth** - Full-channel collections operation. Includes: Everything in Starter; AI voice agents in 10 Indian languages plus Hinglish; Human telecaller console with live transfer; Field operations app; AI intelligence analytics; QA sampling and audit workflows; Priority support. **Scale** - Multi-portfolio, multi-team lenders. Includes: Everything in Growth; Alternate MetaData integration; Advanced allocation strategies; Custom roles and permission matrix; Sandbox tenant for strategy testing; Named account engineer. Q: Why are there no rupee figures on this page? A: Because a real quote depends on your book size and channel mix, and we would rather price it honestly on a call than print a number designed to be walked past. The metre - per active account plus usage at cost - is stated plainly above, so you can model it before we ever speak. Q: What does 'usage at cost' mean in practice? A: Telephony, SMS, WhatsApp and AI model providers are connected with your own credentials. Their charges go to you at their rates. We do not resell minutes or messages. Q: Is there a minimum commitment? A: Monthly billing, with annual pricing if you want it. No multi-year lock-in to get a fair rate. Q: What does onboarding involve? A: A file mapping session for your LMS export, provider credential setup, and your first flow built together with us. Days, not quarters. Q: Can we start with one cohort? A: Yes, and we recommend it. Bring one delinquent segment, run it end to end, and judge the platform on that cohort's numbers. ## Integrations **Loan management and core banking** - The lender's system of record stays where it is. The platform takes an export, works the book, and returns state. - CSV over SFTP: A nightly extract is enough to start. The upload wizard maps columns, dry-runs the file and commits, with saved mappings per lender. - REST API: Push disbursals, balances and closures in; read dispositions, promises and payments out. Cursor-paginated, idempotent writes. - Webhooks: Subscribe to dispositions, payments, PTPs, DNC changes and flow events, signed and retried. - MIS, CRM and BI: Extracts on demand and webhooks out; the reporting stack you have keeps working. **Telephony** - Calls are placed over the lender's own trunk, so caller IDs, recordings and billing stay with the lender. - Exotel (connects under the lender's own credentials): SIP trunking, virtual numbers, Voice v3 and the WebRTC SDK for the telecaller console. Outbound, inbound and voice broadcast. **Messaging** - SMS, WhatsApp, RCS and email from the same flow as every other channel, with delivery and read signals fed back. - Helo.ai (VivaConnect) (connects under the lender's own credentials): SMS, WhatsApp Business and RCS. Templates bound to TRAI DLT registrations before dispatch. - SendGrid (connects under the lender's own credentials): Email with delivered, opened, clicked and bounced events resuming the flow. **Speech and language models** - The voice agent's ears, brain and voice are swappable per agent. Indian-language providers first. - Sarvam AI (connects under the lender's own credentials): Saarika speech recognition and Bulbul voices for Indic languages; the default cascade. - Deepgram, AssemblyAI, Whisper (connects under the lender's own credentials): Alternative speech recognition, with keyword boosting where supported. - Google Gemini, Anthropic Claude, OpenAI (connects under the lender's own credentials): Conversation models, including real-time speech-to-speech engines where the language allows. - Smallest.ai, Cartesia, ElevenLabs, PlayHT (connects under the lender's own credentials): Text-to-speech and voice cloning for agent personas. **Payments** - Links, UPI, cards, netbanking and NACH, reconciled to the account in near real time. - Razorpay (connects under the lender's own credentials): Payment links and the self-service portal; callbacks post payments to the ledger. - Cashfree (connects under the lender's own credentials): Payment links and collections, with the same reconciliation path. **Alternate MetaData** - When the number is dead, the flow can request fresh coordinates and re-enter contact when they land. - Alternate MetaData provider (connects under the lender's own credentials): Contact enrichment under a recorded, purpose-limited reason, on your own credentials. **Hosting and storage** - Run on attpro's own account, in India. Listed on the Trust Center as sub-processors. - Indian-region cloud hosting: Application, database and cache. Named in the data processing agreement. - Wasabi (Mumbai): Encrypted object storage for recordings, exports and backups. ## Trust and security - Data protection / Data residency in India [active]: Application, database and object storage run in Indian regions. No borrower record leaves India in normal operation. - Data protection / Encryption in transit and at rest [active]: TLS 1.2+ on every connection; databases, backups, recordings and exports encrypted at rest. - Data protection / Envelope-encrypted secrets [active]: Provider credentials are encrypted with per-tenant data keys under a master key; never logged, never shown back in full. - Data protection / PII redaction on transcripts [active]: Call transcripts carry PII redaction before they are stored for QA and analytics. - Data protection / Retention, erasure and legal hold [active]: Recordings and records live on schedules the lender sets; DPDP erasure and legal hold run through the same audited lifecycle. - Isolation and access / Schema-per-tenant isolation [active]: Each lender's data lives in its own database schema. Another tenant's book is not addressable from your session. - Isolation and access / Role-based access, tenant-editable [active]: A permission matrix per tenant; admins control which role can see or do what. - Isolation and access / Multi-factor authentication [active]: TOTP second factor for platform users; enforced for administrator roles. - Isolation and access / Audited support access [active]: Support enters a tenant only through time-boxed, reason-required impersonation that writes to an audit feed the tenant can read. - Isolation and access / Single sign-on (SAML / OIDC) [planned]: Enterprise SSO for platform users. - Evidence and compliance / Hash-chained audit log [active]: Every contact, disposition and payment writes to a Merkle-anchored audit log. A changed record breaks the chain and shows up. - Evidence and compliance / Calling windows enforced at dispatch [active]: RBI Fair Practices, DPDP and TRAI constraints are gates in the dialer, not policy documents. A call outside the window is never placed. - Evidence and compliance / Recording disclosure enforced [active]: The disclosure is played by the engine on every call, not left to the agent. - Evidence and compliance / DLT template binding [active]: SMS dispatches only on TRAI DLT-registered templates. - Evidence and compliance / DRA-certified, police-verified people [active]: For managed and hybrid engagements: IIBF DRA certification and a Police Clearance Certificate before anyone works an account. - Resilience / Backups with restore verification [active]: Automated encrypted backups; restores are exercised on a schedule, not assumed. - Resilience / Health monitoring and alerting [active]: Built-in ops console with host, container and job health; alerts to on-call by email and WhatsApp. - Resilience / Published availability target [on-request]: A contractual uptime commitment in the master service agreement. - Resilience / Independent penetration test [planned]: A third-party test of the platform, with a summary letter available under NDA. - ISO/IEC 27001 [planned]: Controls are designed against it; the certification audit is on the roadmap and will be dated here when scheduled. - SOC 2 Type II [on-request]: Undertaken on enterprise demand, funded by the first contract that requires it. - DPDP Act readiness [active]: Consent, retention, erasure, grievance officer and breach-notification procedures in place; a readiness statement is available. - RBI outsourcing and DRA norms [active]: Managed-recovery staff hold IIBF DRA certification; conduct controls are audited internally every cycle. - Responsible disclosure [active]: A published process with acknowledgement and fix timelines and a safe harbour for good-faith research. - Application and database hosting: Indian-region cloud, named in the DPA, India. Compute, Postgres and Redis for the platform - Object storage: Wasabi (Mumbai region), India. Recordings, exports and encrypted backups - Transactional email: SendGrid (Twilio), United States. Platform notifications and website replies; no borrower content - Website lead delivery: Configured CRM or messaging webhook, India. Demo and contact form submissions only ## Legal documents **Privacy policy** (https://attpro.collbox.in/legal/privacy, effective 2026-08-09, updated 2026-08-29): This website collects only what you type into a form, uses it to reply to you, sets no advertising trackers, and deletes enquiry records on a schedule. Borrower data inside the attpro platform is processed on each lender's instructions under a separate agreement. Sections: 1. Scope of this policy; 2. What we collect; 3. Cookies and local storage; 4. Why we process it; 5. Lawful basis and consent; 6. Who we share it with; 7. Where it is kept; 8. How long we keep it; 9. How we protect it; 10. Your rights; 11. Children; 12. Changes to this policy; 13. Contact. Full text on the page. **Terms of service** (https://attpro.collbox.in/legal/terms, effective 2026-08-09, updated 2026-08-29): This site describes the attpro platform for evaluation. Nothing here is an offer, legal advice or a commitment; commercial terms are set in a signed agreement, and the platform itself is governed by that agreement. Sections: 1. Acceptance; 2. What this website is; 3. No legal or regulatory advice; 4. The platform and services; 5. Acceptable use; 6. Intellectual property; 7. Confidential information; 8. No warranty; 9. Limitation of liability; 10. Third-party links; 11. Governing law; 12. Changes; 13. Contact. Full text on the page. **Grievance redressal** (https://attpro.collbox.in/legal/grievance, effective 2026-08-09, updated 2026-08-29): A named officer, a 48-hour acknowledgement, a 15-day substantive response, and a route to the lender and to the RBI Ombudsman if we cannot resolve it. Every complaint is judged on the evidence trail, not on memory. Sections: 1. What this process covers; 2. Named ownership; 3. How to file a complaint; 4. Timelines; 5. How we investigate; 6. If you are not satisfied; 7. Records and reporting. Full text on the page. **Responsible disclosure** (https://attpro.collbox.in/legal/security-disclosure, effective 2026-08-09, updated 2026-08-29): If you find a security issue in this website or the attpro platform, tell us privately. We acknowledge within 48 hours, keep you informed through the fix, and do not pursue good-faith research conducted within these rules. Sections: 1. Scope; 2. How to report; 3. What we ask of you; 4. What we commit to; 5. Safe harbour; 6. How we rate severity; 7. Acknowledgements. Full text on the page. **Accessibility statement** (https://attpro.collbox.in/legal/accessibility, effective 2026-08-29, updated 2026-08-29): This website is built to WCAG 2.2 level AA. Every page is checked in both themes for contrast, keyboard use, heading structure and target size, and the checks are scripted so they run on every release. Known limits are listed, and there is one address for anything we missed. Sections: 1. Our commitment; 2. What is in place; 3. How we test; 4. Known limitations; 5. Tell us what we missed. Full text on the page. ## Working notes ### NPA, SARFAESI and what they mean on a collections floor (https://attpro.collbox.in/resources/npa-and-sarfaesi-for-collections-teams) Classification and enforcement are usually treated as somebody else department. They set the clock a collections team is working against, and knowing where the thresholds sit changes what you do in month two. Published 2026-08-30, 2 min read. Non-performing asset classification and the enforcement route available on secured lending are subjects a collections floor rarely studies, on the reasonable grounds that finance and legal own them. The trouble with that division of labour is that both set deadlines the collections team is actually racing, and a team that does not know the deadlines cannot prioritise against them. **Why classification changes behaviour** An account approaching the point of classification is worth disproportionate effort, because the cost of it crossing the line is borne by the lender in provisioning and by the borrower in credit reporting. That makes the weeks before the threshold the highest-leverage period in the whole recovery timeline, and it is precisely the period most operations treat as routine deep-bucket work. **What secured enforcement changes** Where the lending is secured, the SARFAESI framework gives certain lenders a route to enforce security without going to court, subject to notice periods and process. For a collections team the relevant effect is not the mechanics but the leverage and the timeline: there is a real alternative to persuasion, it takes time to invoke, and it is credible only if the operation actually uses it. Threatening a process the lender never invokes is both ineffective and, once borrowers learn it is empty, corrosive. **The conduct boundary matters especially here** - Notice periods exist and are not negotiable by a caller in a hurry. - Describing enforcement as imminent when no notice has been issued is a misrepresentation, whatever the intent. - Unsecured lending has no such route, and implying it does is the most common version of this error. - Anything said about legal consequences should be sayable in a recording that a regulator may later hear. **What the floor should actually track** - Days to the next classification threshold, visible on the account rather than known to finance only. - Whether the account is secured, since it changes both the leverage and the arithmetic. - Whether a notice has been issued, so nobody discusses a stage the account has not reached. - Whether the account is in a legal process, which should remove it from ordinary calling entirely. **The practical point** None of this makes a telecaller into a lawyer. It makes the prioritisation honest: work hardest where the clock is closest, be precise about what stage an account has actually reached, and stop ordinary collections activity the moment an account enters a formal process. Those three habits prevent most of the trouble that arises where recovery and enforcement meet. ### Settlements and one-time settlement, done properly (https://attpro.collbox.in/resources/settlements-and-one-time-settlement) A settlement is a decision to take less money now instead of more money later, or none at all. Made well it is the best outcome available. Made casually it is a discount given to borrowers who would have paid. Published 2026-08-30, 2 min read. Late in a book, full recovery stops being the realistic outcome for a portion of accounts. A settlement, whether a one-time payment or a structured reduction, recognises that and closes the account for a sum both sides can live with. The instrument is sound. The way it is usually operated is where the losses come from. **The two failure modes** - Settling too readily. Offering a reduction to a borrower who was going to pay in full is a pure loss, and word of an easy settlement policy travels through a borrower base faster than any lender expects. - Settling too late. Holding out for full recovery on an account with no capacity converts a recoverable seventy per cent into an uncollected hundred. **What should drive the decision** Not the borrower persistence, and not the caller month-end position. The decision should rest on an estimate of what this account is actually likely to yield if worked normally, the time that would take, and the cost of doing it. A settlement is worth accepting when the offer exceeds the risk-adjusted present value of continuing. Written that way it is arithmetic, and arithmetic can be delegated to a rule rather than to a negotiation. **Authority has to be structured** - Bands by bucket and by account characteristics, so most cases resolve without escalation. - A named approver above the band, with the approval recorded against the account rather than in an inbox. - A floor below which nothing is accepted without senior sign-off. - An audit trail showing who approved what, and on what basis, because this is the area a review will look at first. **The paperwork is the product** A settlement that is not documented properly is a future dispute. The borrower needs an unambiguous letter stating the amount, the deadline, and precisely what happens on payment: which account closes, what the outstanding becomes, and what will be reported to the credit bureau. That last point causes more post-settlement complaints than everything else combined, because borrowers frequently expect a settled account to be reported as closed and it is not. **Broken settlements** A settlement agreed and not paid should return the account to its previous state cleanly, with the original amount restored and the offer withdrawn on a defined rule rather than at a caller discretion. Operations that leave broken settlements in an ambiguous state end up negotiating twice against a lower anchor, which teaches exactly the wrong lesson. **Measure the policy, not the case** Track settlement rate by bucket, average haircut, the share of settlements that were paid in full and on time, and, most usefully, recovery on the accounts you declined to settle. If those declined accounts eventually yielded less than the offer you refused, the policy is too tight, and no individual case review would ever have told you. ### What is different about digital-lending collections (https://attpro.collbox.in/resources/digital-lending-collections) The borrower was acquired in minutes, never met anyone, and holds the loan entirely on a phone. Every one of those facts changes recovery, and mostly not in the lender favour. Published 2026-08-30, 2 min read. Digital lending compresses origination into a few minutes and a few screens. That is its advantage and, for collections, its central difficulty: the lender has no relationship to draw on, the borrower may barely remember which app they borrowed from, and everything about the recovery has to be reconstructed through the same phone that granted the loan. **What changes** - Short tenures. There is less time for a recovery strategy to work before the loan is simply over. - Thin relationship. No branch, no officer, often no memory of the brand. - App-first expectations. A borrower who did everything in an app will not adapt to a callback-and-cheque process. - Speed of deterioration. On a thirty-day loan, day seven is already late. - Multiple simultaneous borrowings, often across several apps, which makes prioritisation between lenders a real competition. **Brand recognition is a collections problem** A borrower who does not recognise the name calling them treats the call as fraud, which in this segment is a rational assumption. The identification burden is heavier here than anywhere else: the lending app name, the loan amount, the date it was taken. Getting the borrower to accept that the debt is real is often the first half of the conversation, and a caller who leads with the arrears has skipped it. **The conduct exposure is higher, not lower** This segment has produced the most visible collections misconduct in India, largely through contact-list access, messaging third parties and automated harassment at volume. The reputational consequences have landed on the whole category, which means a digital lender collecting properly still has to prove it. Building the constraints into the system, and being able to show them, is worth more here than a policy document. **Where automation genuinely fits** The volumes, the short cycles and the small tickets make automated contact the only economic option for the bulk of the book. That is fine. What it demands is that the automation is well behaved by construction: hard caps on frequency, real quiet hours, immediate opt-out, no contact with anyone other than the borrower, and an easy route to a person. Automation at this scale amplifies whatever the design is, including its mistakes. **The number to watch** Recovery in the first ten days after due date, as a share of total recovery on the cohort. In digital lending it should be a large majority. If it is not, the operation is being run on a monthly rhythm that the product does not have, and the money is being chased after the point where it was realistically available. ### Two-wheeler and consumer-durable collections (https://attpro.collbox.in/resources/two-wheeler-and-consumer-durable-collections) High volume, small tickets, thin margins and a secured asset that is often worth less than the cost of recovering it. This is where per-account economics decide the whole strategy. Published 2026-08-30, 2 min read. Two-wheeler and consumer-durable books share a shape: very large numbers of small accounts, spread across geographies, held by first-time or thin-file borrowers. The security exists but is frequently not worth enforcing. Recovery is therefore almost entirely a contact and persuasion problem, at a cost per account that has to stay very low to work. **The economics set the strategy** When an instalment is a few thousand rupees, a single field visit can cost a meaningful fraction of the amount being recovered. That fact, not any philosophy about customer experience, is what pushes these books towards automated early contact. The bucket where a human call is worth making is narrower here than in almost any other product. **What works** - Pre-due reminders, because a large share of the delinquency is timing rather than distress. - Messaging first, with voice reserved for accounts that do not respond to it. - Payment links that work on a low-end phone and a weak connection, because that is the device the borrower has. - Local language by default. These borrowers are not reading English messages. - Dealer and channel context, since delinquency often clusters by point of sale and that is actionable upstream. **Repossession is a last resort with poor arithmetic** For a two-wheeler the recoverable value after seizure, storage and sale is often modest, and for consumer durables it is usually negligible. Both carry high conduct risk and generate the kind of incident that attracts attention. The threat of repossession is also frequently used casually in these books, which is both a conduct problem and a credibility problem once borrowers realise it is not followed through. **The first-time borrower angle** Many of these customers are borrowing formally for the first time, and a fair number of early delinquencies are misunderstandings: what the due date means, what happens if the auto-debit fails, how to pay if it does. Contact that explains rather than demands recovers more of this cohort than pressure does, and it produces borrowers who are still customers a year later. **What to watch** First-instalment default is the single most informative number in these books. It is rarely a collections failure, it is an origination or a mandate-setup failure, and it should be routed back to whoever owns those rather than absorbed as a recovery cost. If nobody upstream is receiving that number every month, the collections team is quietly subsidising a problem it cannot fix. ### Collections for microfinance and JLG books (https://attpro.collbox.in/resources/microfinance-collections) Group lending has its own physics. Centre meetings, joint liability and weekly cycles mean the levers that work on a retail book can actively damage a microfinance one. Published 2026-08-30, 2 min read. A microfinance book looks like a collections problem and behaves like a community relations problem. Ticket sizes are small, frequencies are weekly or fortnightly, repayment happens in groups, and the borrower relationship is mediated by a field officer who knows every member by name. Applying a retail collections playbook to it produces poor recovery and real harm. **What is structurally different** - Repayment is collective. A missed instalment is often a group event rather than an individual one, and the group usually knows before the lender does. - The field officer is the relationship. Centralised calling has to support that relationship rather than compete with it. - Ticket sizes make per-account cost decisive. A ten-rupee contact against a small weekly instalment changes the economics immediately. - Cycles are short. A borrower can be delinquent and cured inside a fortnight, so the reporting rhythm of a monthly book does not fit. **Where joint liability needs care** Joint liability is a credit mechanism, not a licence to apply social pressure. There is a real line between informing a group about a shared obligation and using the group to shame a member, and operations that blur it produce exactly the outcomes that draw regulatory attention. Any automated messaging that touches other members of a group needs to be designed with that line explicit, and defaulted to the conservative side. **What technology should actually do here** - Support the centre meeting rather than replace it: attendance, collections recorded on the spot, receipts issued immediately. - Work offline. Rural connectivity is not an edge case, it is the normal condition, and a field app that requires signal will be worked around. - Keep the cost of a reminder near zero, which usually means messaging rather than voice for the routine cycle. - Give the field officer the account context before the visit, not a call afterwards asking what happened. **The signals worth watching** Centre attendance is a leading indicator that has no equivalent in retail lending. A group whose attendance is falling is a group whose repayment will fall, usually weeks later. Partial collection at a centre, where the group covers a member shortfall, is another: it keeps the number clean while hiding a member in difficulty, and an operation reading only the repayment line will not see it until the group runs out of capacity. **The tone question** These are borrowers with small loans, thin buffers and long relationships with the lender. The recovery approach that works is one that treats a missed week as a conversation rather than an event, and that reserves escalation for genuine refusal rather than applying it on a schedule. That is also, not coincidentally, the approach least likely to end up in a newspaper. ### Where borrower data actually sits, and why the answer has to be specific (https://attpro.collbox.in/resources/data-residency-for-lenders) In India means little on its own. The useful answer names the systems, the copies and the vendors, including the ones that only hold the data for four seconds. Published 2026-08-30, 2 min read. Every collections vendor says the data stays in India. It is usually true of the database and frequently untrue of something else in the chain, because a modern collections stack is not one system. It is a database, an object store for recordings, a telephony provider, a messaging provider, a speech recognition service, a language model, a payment gateway and an Alternate MetaData vendor, and each of those is a place borrower data goes. **The map nobody has until they are asked for it** - Primary database: account, contact and history data. - Object storage: recordings, transcripts, uploaded documents and field photographs. - Telephony: the audio itself, in transit and often at rest for a retention period on the provider side. - Messaging: the message body, which in collections contains a name and an amount. - Speech and language services: fragments of conversation, sent for processing. - Payments: identifiers, amounts and sometimes contact details. - Tracing: whatever you send in the query, which is itself personal data. **Transient processing is still processing** The commonest gap is a service that holds data only momentarily and is therefore not thought of as storage. If a fragment of a borrower conversation crosses a border to be transcribed, that is a transfer, and it belongs on the map whether or not anything was retained. The honest version of a residency answer lists these; the marketing version does not mention them. **Sub-processors are part of your answer** Your vendors have vendors. A lender asking where the data sits is asking about the whole chain, and a partner who cannot name their sub-processors cannot answer the question. Keep the list current, publish it to clients, and commit to telling them before it changes. This is one of the least glamorous and most reassuring things a collections partner can do. **Choice beats assurance** The strongest position is not a promise about where a vendor sends data but the ability for the lender to choose the vendors themselves. Where a lender brings its own telephony, messaging and model credentials, the data goes where the lender has already approved, under contracts the lender already holds. It converts a question of trust into a question of configuration. **The one-page answer worth keeping ready** A single page listing each category of data, where it rests, which vendors process it, in which country, for how long, and under what contract. Every serious BFSI review asks for a version of this. Writing it once, and keeping it current, removes weeks from every subsequent one. ### What a lender asks a collections partner, and what good answers look like (https://attpro.collbox.in/resources/vendor-due-diligence-for-collections) A BFSI vendor review is not a formality to be survived. It is a reasonable set of questions about what happens to your borrowers and your data, and most of them can be answered from the system or not at all. Published 2026-08-30, 2 min read. Any lender placing a book with a collections partner runs a due diligence process, and any partner worth using has already answered these questions for someone else. The questionnaire varies in length and rarely in substance. It is asking three things: can you do the work, will you do it within the rules, and what happens to the data. **Conduct and people** - Are callers and field officers certified and background verified, and can you evidence current status per person? - How is calling conduct monitored, and what share of calls is actually reviewed? - What happens to an agent after a substantiated conduct complaint? - Are agency staff, if any, held to the same standard, and how do you know? **Contact discipline** - Are calling windows enforced by the system or by instruction? - How are frequency caps applied, and are they counted across channels? - How is do-not-contact honoured, and how quickly does it take effect? - Can you produce every contact attempt for a named borrower over the last year? **Data** - Where does borrower data physically reside? - How is it separated from other clients data, structurally rather than by a filter? - Who can access it, how is that logged, and how long are recordings and transcripts kept? - On exit, what is returned, what is deleted, and how is the deletion evidenced? **What a good answer sounds like** A good answer is demonstrable rather than descriptive. Not we enforce calling windows, but here is a call the system refused to place, and here is where the window is configured. Not access is restricted, but here is the access log for this borrower record for the last six months. Vendor reviews are largely an exercise in distinguishing policies from controls, and the fastest way through one is to answer from the system. **The questions a partner should ask back** Diligence runs both ways. A partner should want to know what data will be shared and under what terms, what the lender expects on conduct, who the escalation contact is, and what happens to accounts on recall. A partner who asks none of those has not thought about the relationship past signature. ### A grievance process that actually resolves things (https://attpro.collbox.in/resources/grievance-redressal-that-works) Every lender publishes a grievance mechanism. The difference between one that works and one that exists is whether a complaint changes anything other than its own status. Published 2026-08-30, 2 min read. Grievance redressal is usually built to satisfy a requirement: a named officer, an email address, a page on the website, a stated turnaround. All of that is necessary. None of it is sufficient, because a process can meet every published commitment while resolving nothing, and borrowers can tell the difference long before an auditor can. **The four things a working process has** - A single intake that catches complaints from every route, including the ones that arrive as a sentence in the middle of a collections call. - A clock that starts at first contact rather than at the point somebody formally logged it. - Access to the evidence: the recording, the transcript, the contact history and the account state, in one place. - An outcome that can change something upstream, rather than only closing the ticket. **The intake problem is the big one** Most complaints never reach the grievance channel. They are said to a telecaller, who notes them or does not, and the borrower escalates only when nothing happens. By the time it arrives formally it has aged, hardened, and often gone to the regulator or to social media first. An operation that gives callers a one-click way to raise a complaint from inside the call, and that treats doing so as good behaviour rather than an admission, sees a very different volume and a very different tone. **Evidence, quickly** The first thing an investigator needs is what actually happened. If assembling that takes two days of requests to three teams, the published turnaround is being spent on retrieval rather than resolution. This is where recording indexing, transcripts and a complete contact history stop being compliance overhead and become the thing that lets you answer a borrower properly within the week. **Close the loop upstream** A complaint about a call made outside hours should end with someone checking why the window allowed it. A complaint about repeated contact should end with the frequency cap being examined. If complaints are only ever resolved individually, the same complaint arrives again, and the pattern is only visible to the person receiving them. Categorise complaints, count the categories monthly, and treat a rising category as a defect rather than a coincidence. **The measure that matters** Not the count of complaints, which will rise if you make it easier to complain, and that is a good thing. Measure the share resolved within the committed time, the share that recur from the same borrower, and the share that led to a change in a rule, a script or a setting. That last one is the only evidence that the process is connected to the operation. ### Disclosure on a collections call: who you are, why you are calling (https://attpro.collbox.in/resources/disclosure-on-a-collections-call) The opening fifteen seconds of a collections call carry most of its compliance risk and most of its chance of working. They are usually left to the caller to improvise. Published 2026-08-30, 2 min read. A borrower answering an unknown number has three questions, and they are the same three every time: who is this, what is this about, and is it real. A call that answers all three immediately has a conversation. A call that does not gets treated as a scam, which is a reasonable response given how many actually are. **What the opening has to establish** - Who is calling, by name, and on whose behalf. The lender name matters more than the agency name to the person answering. - That the call concerns a specific account, without announcing the debt to whoever picked up the phone. - That the call may be recorded, before anything worth recording is said. - Verification of identity, before any account detail is discussed. **The order matters more than people think** Disclosing the debt before confirming you are speaking to the borrower is the single most common serious error in collections calling. The person who answered may be a spouse, a colleague or a stranger holding a reassigned number, and telling them about the arrears is a disclosure to a third party regardless of intent. Identity first, always, and a script that lets a caller reach the amount before the confirmation is a script waiting to cause an incident. **Recording disclosure is not a formality** Saying the call may be recorded is both an obligation and a protection. It protects the borrower, who knows the conversation is on the record, and it protects the caller, whose account of a disputed conversation is now evidence rather than assertion. It has to come early, because a disclosure made after the substantive discussion has not disclosed anything. **Automated calls do not get an exemption** An AI voice agent has exactly the same obligations, and one additional one: it should not leave the borrower uncertain about whether they are speaking to a person. The identification, the purpose, the recording notice and the identity check all belong in the automated script, enforced by the system rather than the prompt, so that no configuration change can quietly remove them. **How to check yours** Pull twenty recordings at random and time how long it takes each caller to cover the four items above. Then find every call where an amount was mentioned before the identity was confirmed. That second number should be zero, and on most floors that have never looked, it is not. ### DLT registration for collections messaging, without the mystery (https://attpro.collbox.in/resources/dlt-registration-for-collections-sms) Most delivery failures on collections SMS in India are not network problems. They are registration problems, and they are entirely avoidable once somebody owns the template list. Published 2026-08-30, 2 min read. Commercial SMS in India runs through the distributed ledger registration framework operated by the telecom operators under TRAI direction. Senders register, headers are registered, and message templates are registered. A message that does not match a registered template against a registered header does not get delivered, and the sender usually finds out from a report rather than from a person. **The three things that must line up** - The entity, registered once. - The header, the six-character sender ID the borrower sees, tied to that entity and to a category of use. - The template, matching the message body exactly, with variables in defined positions. Delivery failures almost always come from the third. A template approved with two variables cannot carry three. A full stop added to make the message read better is a mismatch. This is why collections messaging should be composed from a managed template library rather than typed by whoever is running the campaign. **Transactional, service and promotional are not interchangeable** The category a template is registered under governs when it can be sent and whether preference scrubbing applies. Collections messages are not marketing, and registering them in a promotional category is both wrong and self-defeating, because it exposes them to preference filtering that removes exactly the borrowers you need to reach. Getting the category right at registration is worth more than any amount of retry logic afterwards. **Where operations lose time** - Approval lag. New templates take time, so the template list has to be planned ahead of the campaign, not during it. - Language variants. Each language is its own template, and a ten-language strategy is ten registrations per message. - Silent drift. Someone edits the copy in the campaign tool and not in the registry, and delivery quietly falls. - Header confusion across group entities, where a borrower receives messages from a header they do not recognise and treats them as fraud. **Treat delivery receipts as strategy, not diagnostics** The receipt tells you whether the message arrived. In collections that is not a technical detail, it is a branch: a delivered message that went unanswered is a contactable borrower who chose not to act, while an undelivered one is an unreachable borrower, and the next step differs completely. An operation that logs receipts but does not act on them is collecting the signal and discarding the value. **The check to run this week** Pull last month delivery rate by template. If one template is materially below the others, it is a registration mismatch rather than bad luck, and it has been quietly costing you contact for however long it has been live. ### DRA certification, and why it is not paperwork (https://attpro.collbox.in/resources/dra-certification-explained) Debt Recovery Agent certification is treated by many operations as a box to be ticked before an audit. Treated as training, it is the cheapest reduction in conduct risk available to a collections floor. Published 2026-08-30, 2 min read. Recovery agents working on behalf of regulated lenders are expected to be trained and certified for the work, and the industry standard route in India is the IIBF debt recovery agent programme. The requirement is well known. What varies enormously between operations is whether the certification is treated as a credential to be collected or as training to be used. **What the training is actually about** The syllabus covers the products, the legal framework, the recovery process and, most usefully, conduct: what an agent may say, where and when they may go, how to identify themselves, what to do when a borrower disputes or complains. That last part is where the value sits, because almost every conduct incident in collections is a person improvising in a situation they had not been prepared for. **The operational questions worth answering** - Is certification checked before a person takes their first live call, or at the next audit? - Does the system know which agents are certified, and does it stop an uncertified user from being allocated accounts? - When a certificate lapses, what happens automatically? - Do agency staff working your book meet the same bar as your own, and can you evidence it without asking the agency? If the answer to the second question is that the roster lives in a spreadsheet, the control is a hope. Certification status belongs next to the user record, and allocation should respect it the same way it respects a calling window. **Certification is a floor, not a ceiling** A certificate says a person was taught the rules once. It does not say they follow them on a difficult Thursday in the last week of a month. That is what call monitoring, dispute review and a real complaint process are for, and an operation that relies on the certificate alone has bought the evidence of training without the effect of it. **Screening belongs in the same conversation** Certification is about competence. Background verification is about suitability, and the two are usually handled by different people at different times, which is how a certified agent with an unchecked history ends up on a doorstep. Treat them as one gate: nobody is allocated a live account until both are on file and current. **Why this is worth more than it costs** The cost of certifying and screening a floor is small and predictable. The cost of a single conduct incident is neither. It arrives as a complaint, escalates to the lender, and becomes a question about the whole operation rather than one person. Very few investments in collections have that ratio. ### Alternate MetaData in India: when to spend, and what to expect back (https://attpro.collbox.in/resources/alternate-metadata-in-india) Tracing is bought as a magic answer to unreachable accounts and usually delivers a partial one. Used with a rule about when to trigger it, it is one of the better rupees a collections operation spends. Published 2026-08-30, 2 min read. A meaningful share of any aged book is not refusing to pay. It is simply unreachable: the number is dead, the address is stale, the employer has changed. Every contact attempt against those accounts is spend with a guaranteed zero return, which is what makes tracing interesting. It is not a recovery tool. It is a way to stop wasting the recovery tools you already have. **Trigger it on the right signal** The trigger should be evidence that the contact details are wrong, not that the borrower is not paying. Those are different problems and only one of them is solved by a new phone number. This is where a precise disposition list pays for itself: invalid number and wrong person are traceable states, while ringing and no answer are not. - Number invalid or disconnected on two attempts. Trace. - Answered by someone who says the number has been reassigned. Trace, and mark the old number dead so nobody dials it again. - Ringing with no answer across several days and time slots. Do not trace yet. Change the time of day first, then the channel. - Field visit returns address not found. Trace the address, which is a different product from tracing a number. **What you should expect to get** A partial answer. Not every trace returns something, and not everything returned is current. Treat results as candidates to be verified by contact rather than as facts to be written into the master record. The operational discipline that matters is what happens to a traced number that turns out to be wrong: it should be marked, not silently retried next month. **The conduct line, which is not optional** Tracing sits close to a boundary. Locating a borrower is legitimate. Contacting their relatives, employer or neighbours about the debt is a different act, and treating a traced third-party number as an alternative line to the borrower is where operations get into trouble. Decide the policy centrally, write it into the system, and do not leave it to a caller under pressure at month end. **Measuring whether it is worth it** - Hit rate: traces that returned anything usable. - Contact rate on traced details, which is the number that matters, since a returned number nobody answers has changed nothing. - Recovery on traced accounts against the cohort that was not traced. - Cost per re-established contact, which is the figure to compare against continuing to dial a dead number. Run those four for a quarter and the question of how much to spend on tracing stops being a matter of opinion. ### Designing an escalation ladder that stops at the right rung (https://attpro.collbox.in/resources/designing-an-escalation-ladder) Escalation is easy to design going up and almost never designed going down. The result is an operation that spends its most expensive resources on borrowers who would have paid after a message. Published 2026-08-30, 2 min read. An escalation ladder is the sequence of increasingly costly interventions applied to an account that has not resolved: a message, an automated call, a human call, a field visit, legal notice. Most lenders have one. What most lack is a rule for stopping, and a ladder with no brake is a machine for spending money. **Order the rungs by cost, then by intrusion** The two orderings mostly agree, which is convenient. A message costs paise and intrudes least. A field visit costs the most and intrudes most. Starting at the bottom is both commercially and ethically correct, and the argument for skipping rungs is almost always impatience dressed as efficiency. **The rules that should govern moving up** - Only after the current rung has genuinely failed, which means delivered and unanswered rather than simply sent. - Never faster than the borrower could reasonably have responded. Escalating within an hour is not escalation, it is pressure. - Not at all if the borrower has engaged. A borrower who replied, disputed or asked for time has moved the account into a different process. - Subject to a cost ceiling for the cohort. A five-hundred-rupee arrear does not justify a field visit, and the ladder should know that without a supervisor intervening. **The missing half: coming back down** When a borrower makes contact, makes a part payment or agrees a plan, the account should descend the ladder rather than continuing up it. Very few implementations do this, which is why borrowers who are cooperating still receive escalating pressure, and why a good proportion of complaints come from people who were actually paying. De-escalation is the single most under-implemented idea in collections strategy. **Stopping altogether** Some accounts should exit the ladder. Confirmed hardship, a dispute under investigation, a deceased borrower, an account in a legal process, or a cohort where the marginal cost of the next rung exceeds the expected recovery. Each of these needs an explicit exit rather than a caller deciding informally, because informal exits are invisible and unauditable. **How to know yours is working** Look at what proportion of accounts reach the most expensive rung, and what those accounts recovered. Then look at what proportion resolved at the first rung. In a healthy ladder the first rung does most of the work and the last rung is rare and selective. If the distribution is flat, the ladder is not a strategy, it is a queue that everybody eventually reaches the end of. ### In-house, agency or hybrid: choosing a collections model (https://attpro.collbox.in/resources/in-house-agency-or-hybrid) The decision is usually made on cost per rupee recovered and then regretted on conduct, control and data. Here is the fuller comparison, including what each model is genuinely better at. Published 2026-08-30, 2 min read. Every lender past a certain size makes this choice, revisits it after an incident, and often lands somewhere in the middle. The three models are not ranked. They trade different things against each other, and which trade is right depends on the book, the stage of the lender and how much conduct risk sits with the brand. **In-house** Best where conduct risk is high, where the borrower relationship continues after the arrears are cleared, and where the early bucket is large. You control training, tone and escalation directly, the data never leaves, and the feedback loop into underwriting is short. The costs are fixed, hiring is continuous, and geographic coverage is expensive to build for a book that is spread thin. **Agency** Best for reach, for deep buckets where the economics only work on commission, and for surge capacity. You buy coverage in cities where you have no presence and specialists in situations you handle rarely. What you give up is visibility and, unless the contract is unusually tight, control of the conversation. Complaints still arrive at your brand, and the regulator still regards the borrower as yours. **Hybrid, which is what most large books end up doing** - In-house for pre-due through the early bucket, where tone matters most and volume is highest. - Agency for the deep buckets and for cities without a stationed team. - A single platform across both, so an account handed to an agency does not disappear from view. - One conduct standard, audited the same way regardless of who is holding the phone. **The questions that decide it** - If a borrower complains about an agency caller next month, can you produce the recording within the day? - When an account is recalled from an agency, what happens to the copy of the data they hold? - Do agency users log in individually, so an access log names a person? - Can you compare agency performance to in-house on the same cohort, or only on the accounts each happened to receive? That last one is where most comparisons fail. Agencies usually get the harder accounts, then get judged against in-house numbers built on easier ones. Unless you can hold the cohort constant, the comparison is measuring allocation rather than performance. **The direction of travel** As a book grows, the early bucket grows fastest and is the cheapest to automate, which pushes it in-house. The deep tail grows slowly and stays specialist, which keeps it with agencies. Most operations that get this right end up doing more of their own early work over time and less of their own late work, rather than choosing one model for everything. ### Cost to collect, computed honestly (https://attpro.collbox.in/resources/cost-to-collect) Most cost-to-collect numbers are a commission rate with some overhead added. The useful version tells you which rupees you are spending to chase rupees you were never going to get. Published 2026-08-30, 2 min read. Cost to collect sounds like a single number and is really a family of them. Computed at the portfolio level it is almost useless, because it averages the effortless recoveries with the hopeless ones and produces a figure that cannot guide a decision. Computed per cohort it becomes the most actionable number in the operation. **What belongs in the numerator** - People: telecaller and field officer salaries, supervision, quality, training, attrition and rehiring. - Contact: telephony minutes, SMS and WhatsApp charges, and the ones people forget, failed and unanswered attempts. - Technology: platform, dialer, recording storage, integrations. - Third parties: agency commission, Alternate MetaData, legal, field vendors. - Compliance: certification, audits, and the cost of handling complaints and disputes. The item most often missing is the cost of unproductive contact. A floor that dials four times to reach once is paying for four dials, and if the number that finally connects was wrong all along, it paid four times for nothing. Alternate MetaData looks expensive until you price the alternative. **Compute it per cohort, not per portfolio** Cost to collect per bucket, per product, per vintage, per ticket size. The pattern that emerges in almost every book is the same: a band of accounts where recovery is cheap, a band where it is expensive but positive, and a tail where the operation reliably spends more than it recovers and continues to do so because nobody has drawn the line. Finding that tail is the entire point of the exercise. **The comparison that matters is marginal, not average** Average cost to collect tells you what the operation costs. Marginal cost, what the next unit of effort on this cohort yields, tells you what to do tomorrow. A cohort with a good average and a terrible marginal return is one you should stop working harder, and an average will never show you that. **Where automation actually changes the number** It does not change the cost of the hard conversations, which still need people. It changes the cost of the easy ones, which is most of the volume, and it changes what your people are doing with the hours it frees. The honest way to evaluate it is not cost per contact, where automation always wins, but recovery per rupee of total operating cost, where it only wins if the freed hours were pointed somewhere useful. ### Kept-promise rate: the metric that separates activity from recovery (https://attpro.collbox.in/resources/promise-to-pay-kept-rate) Calls made, contacts reached and promises taken are all measures of effort. Promises kept is the first one that correlates with money, and it is the one most floors do not compute. Published 2026-08-30, 2 min read. A collections floor can have an excellent day by every dashboard it looks at and collect nothing. Dials, connects and promises are all counts of effort, and effort is easy to generate. The kept-promise rate, the share of promises that actually turn into payment by the promised date, is where effort meets reality. **Why so few operations have the number** Usually because the promise was never recorded as a structured thing. A note that says will pay soon cannot be measured. A promise needs a date and an amount, captured as fields, or the whole downstream calculation is impossible. Where the number is missing, the cause is almost always the disposition list rather than the reporting. **What a low kept rate is telling you** - Promises are being extracted rather than agreed. A borrower who says yes to end the call will not pay. - The amount was unaffordable. A promise for the full arrears from someone who can manage a third is a scheduled failure. - There was no reminder between the promise and the date, so an honest intention got overtaken by the month. - Paying was harder than agreeing. If the borrower has to find a portal, log in and locate the loan, some share will not. - The money arrived and was not matched, so the promise looks broken in your system and kept in theirs. **The things that reliably raise it** Take smaller promises. A partial amount that gets paid is worth more than a full amount that does not, both in cash and in what it teaches you about the borrower. Send the payment method during the conversation rather than after. Remind on the day before and the morning of, referencing the borrower own commitment rather than the policy. And close the loop with a confirmation, which prevents the follow-up call that undoes the goodwill. **Segment it or it will mislead you** Kept rate by caller tells you who is agreeing to fiction. By bucket, it tells you where promises stop being a useful instrument. By promise size relative to the instalment, it tells you where your callers should be pitching. And by channel of capture, it tells you whether promises taken by an automated agent hold as well as those taken by a person, which is a question worth having evidence about rather than opinions. **One number to pair it with** Track time from promise to payment alongside it. A high kept rate with payments landing on the last possible day means your reminders are working. A high kept rate with payments landing immediately means you are probably taking promises from people who were going to pay anyway, and the real work is elsewhere. ### Roll rates: the number that tells you about next quarter (https://attpro.collbox.in/resources/roll-rates-explained) Recovery percentage tells you how last month went. Roll rate tells you what is coming. It is the closest thing collections has to a leading indicator, and it is usually calculated wrong. Published 2026-08-30, 2 min read. A roll rate is the share of accounts in one bucket at the start of a period that have moved to the next bucket by the end of it. Ten thousand accounts in 1 to 30 at the start of the month, and fifteen hundred of them in 31 to 60 at the end, is a fifteen per cent roll. It is a simple number that most operations either do not compute or compute in a way that hides what they need to see. **Why it beats recovery percentage** Recovery percentage is a ratio of money collected to money due, and it is dominated by the composition of the book. A month with more easy accounts looks like a good month. Roll rate follows the same cohort forward, so it isolates whether the operation actually changed behaviour, and it moves before the recovery number does. That is what makes it worth watching weekly rather than at month end. **Three ways it gets computed wrong** - Counting accounts that entered the bucket mid-period. The cohort has to be fixed at the start or the denominator drifts and the trend is noise. - Ignoring cures. An account that went from 31 to 60 back to current is a different outcome from one that stayed at 31 to 60, and merging them hides your best result. - Reporting by value only. Value roll and count roll answer different questions, and a book where the large accounts behave differently from the small ones needs both. **What to do with it once you have it** Segment it. Roll rate by product, by vintage, by originating channel, by city, by whether first contact was made within the first week. That last cut is the one that usually pays for the whole exercise, because it is the first honest measure of whether early contact is doing anything. If accounts contacted in week one roll at the same rate as accounts contacted in week three, your early-bucket effort is decorative. **Backward roll deserves a name too** Cure rate, the share of a bucket that improves rather than worsens, is the mirror of roll and is reported far less often. An operation optimising only against forward roll will happily hold accounts static. One that watches cures is measuring whether it is actually resolving anything. **A caution** Roll rates respond to changes in policy as much as to changes in performance. A new restructuring scheme, a change in what counts as a cure, or a write-off run will all move the number without anyone having collected differently. Annotate the series with what changed, or somebody will eventually present a policy artefact as an achievement. ### DPD buckets, and why each one needs a different conversation (https://attpro.collbox.in/resources/dpd-buckets-explained) Days past due is the oldest number in collections and the most casually used. The buckets are not a reporting convention. They are four different problems that happen to share a book. Published 2026-08-30, 2 min read. Days past due counts how long an instalment has been unpaid. Everything else in collections hangs off it: who works the account, on which channel, how often, with what authority to settle. Yet most operations treat the bucket as a label for reporting rather than as the thing that should decide the conversation. **What each bucket actually is** - Pre-due and 1 to 30. Mostly forgetfulness, salary timing and payment friction. The borrower is not a defaulter and should not be spoken to as one. - 31 to 60. The first real signal. Something changed, and the useful work is finding out what, before it hardens. - 61 to 90. Distress or refusal. The conversation is a negotiation and the outcome usually needs a structure rather than a promise. - 90 plus. The account has crossed into non-performing territory. Recovery now competes with legal remedies and the arithmetic of what is worth pursuing. **The mistake: one script, four buckets** Using the same tone at day five and day ninety-five fails in both directions. Early, it alienates a customer who simply forgot and who will be with you for another four years. Late, it wastes a contact that needed to open a serious conversation. The single highest-return change most floors can make is to stop treating the early bucket as collections and start treating it as service. **Bucket movement is the number, not bucket size** How many accounts are in 31 to 60 today tells you little. How many of last month 1 to 30 accounts are now in 31 to 60 tells you whether the operation is working. That is the roll rate, and it is the difference between a report that describes the past and one that predicts the next quarter. **Where the buckets lie to you** - Part payments. A borrower who pays half keeps ageing, and a bucket alone will not show you that they are engaging. - Restructured accounts, which reset the clock without resetting the risk. - Multiple loans to one person, where one loan is current and another is deep. The bucket is per loan; the borrower is one. - Month-end timing, where a payment made on the thirty-first and posted on the first moves a whole cohort for reasons that are purely calendar. **The practical test** Take a day of calls and ask, for each one, whether anything about it would have been different if the account had been in a different bucket. If the answer is mostly no, the bucket is doing nothing except appearing on a report, and the strategy is really one strategy pretending to be four. ### Integrating collections with your loan management system (https://attpro.collbox.in/resources/integrating-collections-with-your-lms) The integration is rarely hard technically. It is hard because two systems disagree about what an account owes, and the disagreement surfaces in front of a borrower. Published 2026-08-30, 2 min read. Every collections platform has to sit next to the system of record. The lender loan management system knows the contractual truth: what is owed, what was paid, what the charges are. The collections platform knows the operational truth: who was contacted, what they said, what they promised. Keeping those two aligned is most of the integration work, and almost none of it is about the API. **Decide what is authoritative, once** The outstanding amount has exactly one owner, and it is the LMS. The disposition, the promise and the contact history have exactly one owner, and it is the collections platform. Ambiguity here is what produces the worst failure in collections: a caller quoting an amount the borrower has already paid. Write the ownership down before writing any code. **The three integration shapes, in increasing order of freshness** - File exchange. A daily file in, a daily file out. Unfashionable, extremely reliable, and correct for most books. The cost is staleness: a payment made at noon is invisible until tomorrow. - Scheduled API pull. Fresher, more moving parts, and it needs a plan for what happens when the LMS is down during a business window. - Event-driven. The LMS tells collections when something changes. Freshest, most work, and worth it mainly when same-day payment visibility changes what a caller would say. Most operations should start with files and move only when a specific pain justifies it. The wrong reason to build events is that it sounds more modern. The right reason is that your callers are quoting stale amounts and it is costing you. **The fields that cause the arguments** - Which amount is being collected: instalment, total arrears, or arrears plus charges. Name the field unambiguously and use one name on both sides. - The bucket. If both systems compute DPD independently they will eventually disagree, usually around month end. - Status changes. A closed, settled or written-off account that is still being called is an incident, so status has to travel quickly and be honoured immediately. - Do-not-contact and consent flags, which usually live in the LMS and must be enforced in collections. **Design for the LMS being unavailable** It will be, during a window that matters. The collections platform should degrade rather than stop: keep working the accounts it already holds, queue what it needs to send back, and make the staleness visible to the caller rather than hiding it. A caller who can see that the balance is as of this morning behaves correctly. A caller who assumes it is live does not. **What to test before go-live** Not the happy path. Test a payment made between two syncs, an account closed while a flow was mid-journey, a borrower whose phone number changed in the LMS, and a file that arrives with a thousand rows missing. Those four are what the first month will actually contain. ### Call recordings: keeping them, finding them, and producing them (https://attpro.collbox.in/resources/call-recordings-at-scale) Recording every call is the easy part. The hard parts are finding one call two years later, proving it has not been altered, and knowing when you are allowed to delete it. Published 2026-08-30, 2 min read. Recording is now standard on any collections floor worth auditing, and most operations do it. Far fewer can retrieve a specific conversation from eighteen months ago in the time a regulator or a customer complaint gives them, and fewer still can say with confidence that the file has not been touched since it was made. **Retrieval is the real requirement** A recording nobody can find is a storage cost, not evidence. Retrieval means being able to go from a complaint, which usually arrives as a name, a phone number and an approximate week, to the exact conversation, in minutes. That requires the recording to be indexed against the loan, the borrower, the caller, the campaign, the disposition and the timestamp, and it requires all of those to have been captured at the time rather than reconstructed afterwards. **Transcripts change what the archive is for** An archive of audio is searchable only by metadata. An archive of transcripts is searchable by what was said, which turns a compliance cost into an operational asset: every call where a specific phrase was used, every conversation where a borrower mentioned job loss, every case where the disposition recorded and the words spoken disagree. That last one is the highest-value quality query a collections operation can run, and it is impossible without transcripts. **Integrity, plainly** - Write once. A recording that can be overwritten is not evidence. - Hash on creation and keep the hash where the file is not, so alteration is detectable rather than deniable. - Log access. Who listened to a borrower conversation, and when, is itself a thing you will be asked. - Keep the chain: which call, which agent, which account, which consent state at the time. **Deletion is an obligation too** Storage being cheap is not a retention policy. Recordings contain personal data, often including details about a borrower health, family and employment that were volunteered in the course of an explanation. Keeping them forever because nobody chose a period is the most expensive posture available: it maximises what a breach would expose and leaves you unable to answer an erasure request cleanly. Set a period per category, apply it automatically, and log the deletions so the policy is demonstrable. **The two-minute test** Take a real complaint from six months ago. Time how long it takes somebody to produce the recording, the transcript, the disposition and the identity of the caller. If that takes more than a few minutes, the archive is not doing the job it is being paid for, and the gap will only be discovered at the worst possible moment. ### A collections data model that survives five lakh accounts (https://attpro.collbox.in/resources/a-collections-data-model-that-scales) Systems that work fine on a pilot book of ten thousand accounts fail in specific, predictable ways at five lakh. Most of the failures are decisions made in the first month. Published 2026-08-30, 2 min read. Scale in collections is not mainly about traffic. It is about the number of rows that accumulate behind each account: every contact attempt, every message receipt, every disposition, every flow step, every audit entry. A book of five lakh accounts worked for a year is a few hundred million rows of history, and the parts of the system that get slow are the parts nobody thought of as the product. **The account is not the unit** The first modelling mistake is treating the borrower as the unit of work. A person can hold several loans, and the same phone number can belong to two customers in a badly maintained file. Recovery is worked per loan, but contact is experienced per person, and a system that cannot hold both ideas at once will either call the same person three times in a morning or fail to notice that they cured one loan while defaulting on another. **History grows without limit, and has to be designed for** - Contact history is the largest table you will have, and it is written constantly and read narrowly. It wants partitioning by time, not one table growing forever. - Audit entries are append-only and never updated. Treat them that way and they stay cheap. - Recordings and transcripts do not belong in the database. Store the pointer, not the payload. - Anything you might want to report on by month should carry the month in a way that does not require scanning a year of rows to find out. **The queries that get slow are the ones nobody benchmarked** Everyone tests the borrower list. Nobody tests what happens when a supervisor opens one borrower with four hundred contacts against them, or when a report asks for kept-promise rate by bucket by campaign for a quarter, or when the dialer asks which of two lakh accounts are dispatchable right now. Those three shapes, the deep single record, the wide aggregate and the hot eligibility check, are the ones worth designing around. **Isolation between clients is a design decision, not a setting** If you work books for more than one lender, the separation between them has to be structural rather than a filter somebody remembered to apply. Isolation by schema or by database makes a wrong query return nothing instead of returning another lender data, which is the difference between a bug and an incident. **The questions to ask before the pilot, not after** - What is the largest single table after a year at full volume, and what maintains it? - How does a borrower with four hundred contacts render, and how long does it take? - Can a report for last quarter run while the dialer is at peak, without slowing it? - If a client leaves, what does extracting and then deleting their entire book actually involve? ### Closing the gap between a promise and the money (https://attpro.collbox.in/resources/from-promise-to-cash) The promise-to-pay is the moment collections usually calls a win. The money arriving is a separate event, several days and several failure points later, and most of the loss happens in between. Published 2026-08-30, 2 min read. A promise is not a payment. Between the borrower saying yes and the money reaching the account there is a gap, and everything that happens in that gap either helps or leaks. Most collections operations measure the promise carefully and the gap not at all, which is why kept-promise rates are so often worse than anyone expected. **Where promises leak** - The borrower intended to pay and forgot. The most common and the cheapest to fix. - The payment method failed and nobody found out until the due date passed. - The borrower could not work out how to pay, and did not call back to ask. - The amount was ambiguous. Was it the instalment, the arrears, or the arrears plus charges? - The money went somewhere unallocated and sat there, so the account still looks unpaid. **Send the way to pay while the conversation is still warm** The single most effective change most operations can make is to deliver a payment link during the call rather than after it. The borrower has the phone in their hand, the intent is at its peak, and the amount is fresh. Every hour that passes between the agreement and the ability to act on it costs conversion. **Reminders keyed to the promise, not the calendar** A reminder on the day before the promised date, and one on the morning of it, works because it is about a commitment the borrower personally made rather than a policy date they never agreed to. Both should carry the exact amount and the same link. The tone is a courtesy, not a chase, because at this point the borrower has done nothing wrong. **Reconciliation is part of collections, not accounting** A payment that arrives and is not matched to the loan is worse than no payment, because the borrower has paid and the system is still dunning them. That produces the angriest calls a floor takes, and every one of them is avoidable. Payments raised from a collections contact should carry the reference that ties them back to the account and the promise, and anything unmatched should surface as an exception somebody owns rather than sitting in a suspense account. **What to measure** - Kept-promise rate, by bucket and by how the promise was captured. - Time from promise to payment, which tells you whether your reminders are placed well. - Link click rate against payment completion, which separates a delivery problem from a payment-experience problem. - Unmatched payments as a share of receipts. If it is not near zero, part of your floor is chasing money it has already received. ### WhatsApp for collections in India: what works, and what it is not for (https://attpro.collbox.in/resources/whatsapp-for-collections-in-india) It has the reach nothing else in India has, and the highest chance of being read. It is also the channel where a badly designed sequence turns into a screenshot on social media. Published 2026-08-30, 2 min read. WhatsApp reaches Indian borrowers in a way SMS stopped doing years ago. Messages get read, replies come back in the borrower own words, and a payment link in a thread is one tap from the money. It is also the most personal channel a lender uses, which cuts both ways: the same intimacy that makes it effective makes a clumsy sequence feel like an intrusion into a family space. **What it is good at** - Reminders that carry an amount, a date and a link, with no ambiguity about who is asking. - Confirmations. A receipt in the thread ends a category of dispute before it starts. - Re-establishing contact with a borrower who does not answer calls but reads messages. - Documents: a settlement letter or a statement, delivered where it will actually be opened. **What it is not for** Negotiation. A conversation about why someone cannot pay, and what they can pay instead, is not improved by being conducted in writing at whatever pace both parties happen to reply. Use the channel to reach the borrower and to confirm what was agreed. Do the agreeing on a call. **The operational rules that keep it usable** - Template discipline. Business-initiated messages run on approved templates, so the sequence has to be designed in advance rather than improvised by a caller. - Identify the lender in the first line. A borrower who cannot tell who is messaging assumes fraud, and they are right to. - One thread, not many. Multiple numbers messaging about the same loan reads as harassment even when each message is compliant. - Honour opt-out immediately and everywhere. A borrower who says stop on WhatsApp has said it about WhatsApp, and a system that keeps calling has technically obeyed and practically not. - Quiet hours apply here too. A message at 2 a.m. is not gentler than a call at 2 a.m. **Read receipts are a signal, not a scoreboard** The useful thing about the channel operationally is that it reports back. Delivered, read and replied are three different states, and a strategy that treats them the same is wasting the information. Read but not replied, twice, is a contactable borrower who is choosing not to engage, and that is a different next step from a message that never arrived at all. **The test for whether you are using it well** Read your own sequence as though you were the borrower, on a bad week, with the amount overdue and no easy way to pay it. If the thread reads as a business trying to make paying easy, it is working. If it reads as pressure arriving on the same screen as messages from your family, it will produce complaints eventually, and the complaint will be a screenshot. ### AI voice or a human caller: choosing per bucket, not per belief (https://attpro.collbox.in/resources/ai-voice-or-a-human-caller) The question is not whether AI voice is as good as your best telecaller. It is which conversations need your best telecaller at all, and what it costs you to spend them on reminders. Published 2026-08-30, 2 min read. Most arguments about AI calling in collections are conducted at the extremes. One side demonstrates a flawless scripted reminder and declares the floor obsolete. The other plays a recording of a confused bot and declares the technology unready. Both are answering a question no operator actually has, because the real decision is not whether to use AI voice but where in the book to use it. **What separates an easy call from a hard one** Early-bucket contact is mostly information transfer. The borrower knows they are late, the amount is not in dispute, and the useful outcome is a date and a payment link. That conversation has a shape, and a competent agent that follows the script, speaks the borrower language and captures the promise correctly does it as well as a person, at any hour, without a bad day. Hard-bucket contact is negotiation. The borrower has a reason, the reason is often true, and the outcome depends on judgement about what this person can actually pay and what the lender will actually accept. That is human work, and spending human time on reminders is what leaves too little of it for the accounts where judgement changes the outcome. **A defensible split** - Pre-due and 1 to 30: automated voice and messaging, with a human path available on request. - 31 to 60: automated first contact, human follow-up where the first contact produced a dispute, a hardship signal or a broken promise. - 61 to 90: human-led, with automation handling reminders around agreed dates and confirmations after payment. - 90 plus and legal-stage: human, with the platform doing evidence and scheduling rather than talking. The split is a starting point, not a law. It should move as you learn, and the direction it moves is the interesting number: if automated contact keeps producing kept promises deeper into the book, push the line down. If it produces complaints, pull it up. **The three failure modes worth designing for** - The agent cannot understand the borrower. Two failed recognitions in a row should route to a person, not a third attempt. - The borrower is distressed or angry. This needs a human immediately, and the handoff should carry the transcript so nothing is repeated. - The conversation leaves the script. An agent that improvises in a regulated conversation is a liability; an agent that says it will have a colleague call back is not. **How to measure the decision rather than argue about it** Run both on the same cohort for a month. Compare kept-promise rate rather than contact rate, because contact is cheap and promises are the thing that turns into money. Compare complaint rate per thousand contacts separately for each. Compare the cost of the human hours you freed against what those hours produced when they were pointed at the harder bucket. The answer that comes out is specific to your book, which is why nobody else can give it to you. ### What a collections flow engine actually does (https://attpro.collbox.in/resources/what-a-collections-flow-engine-does) Every lender has a recovery strategy. Most of them keep it in a policy document, a set of Excel filters and the head of collections memory. A flow engine is what happens when you write it down once and let it run. Published 2026-08-30, 3 min read. A recovery strategy is a set of rules about who gets contacted, on which channel, in what order, and what happens next depending on how they respond. Almost every lender has one. Very few have it in a form a machine can execute, which is why the strategy that gets applied on a Tuesday afternoon in a busy month is rarely the strategy that was designed. **The three ways a strategy usually lives** - In a document. Accurate, complete, and applied only as well as the person who last read it remembers. - In a set of filters and allocation rules. Better, but static: it decides who to call and then stops having an opinion. - In a flow engine. The strategy runs as a graph, one borrower at a time, and keeps having an opinion after every contact. **The part people underestimate: waiting** Drawing the happy path is easy. Reminder, call, escalate. The difficulty is that collections is mostly waiting, and the waits are the strategy. A run parks after a message goes out and resumes when the delivery receipt arrives, or when it does not. It parks after a field visit is dispatched and resumes on the officer outcome. It parks on a promise and resumes on the due date, taking one branch if the money arrived and another if it did not. An engine that cannot park is not an engine, it is a batch job. The test is simple: can a single borrower journey stay open for six weeks, survive three restarts of the system, and still take the correct branch when a delivery receipt lands on day forty-one? **Branches are where strategies get honest** A flow forces a decision that documents let you avoid. Every node has to say what happens on every outcome, including the ones nobody likes to plan for: the number is wrong, the borrower disputes the amount, the agent never picked up the queued account, the payment gateway timed out. Drawing the graph surfaces the gaps, because an unhandled branch is visible as a dead end rather than invisible as an assumption. **What the engine has to know that a workflow tool does not** - Contact windows and frequency caps, checked at dispatch rather than at design time. - Do-not-contact state, honoured across every channel at once rather than per channel. - Which campaign and which file a borrower currently belongs to, so a strategy change does not double-contact them. - Language, so the message that goes out is in the one the borrower actually reads. - Cost, because a flow that escalates everyone to field visits is technically correct and commercially absurd. **How to tell a real one from a diagram** Ask to see a run that is currently parked, and what it is waiting for. Ask what happens if the signal it is waiting for never arrives. Ask to change one branch on a live strategy and watch whether the accounts already mid-journey adopt the change or finish on the old graph, and whether anybody can tell you which of those two happened. A tool that cannot answer those three questions is drawing pictures of a strategy rather than running one. ### Quiet hours in Indian collections: what the rules actually require (https://attpro.collbox.in/resources/rbi-quiet-hours-explainer) The Fair Practices Code's contact-hours expectation is short. Operationalising it across voice, messaging and field is not. A plain-language walk-through. Published 2026-08-01, 3 min read. The RBI Fair Practices Code expects lenders and their agents to contact borrowers at reasonable times and places. In practice the industry norm is a calling window from morning to early evening, with local sensitivity beyond it. The words are simple; the operational question is where the rule is enforced. **The three places a quiet-hours rule can live** - In training: agents are told the window. Fails on the first hectic day. - In review: calls outside the window are flagged afterwards. The breach already happened. - In the dialer: a call outside the window is never placed. The rule becomes physics. Only the third survives scale. When contact volume is a lakh touches a day across voice, WhatsApp, SMS and field visits, any rule that depends on a person remembering it will be broken daily, and every breach is a complaint waiting to be escalated. **What enforcement-at-dispatch has to cover** - Timezone discipline: windows in IST, not server time. - Every channel, not just voice - a 2 a.m. WhatsApp reads as harassment too. - Campaign-level variation: early-bucket reminders and legal-stage notices deserve different windows. - Evidence: for any contact, the ability to show when it happened and which rule allowed it. **The cases that break a naive window** A single start time and end time handles the easy ninety per cent. The rest is where complaints come from, and each case deserves a decision made once, in the system, rather than argued on the floor every week. - The borrower calls you at 9 p.m. Answering an inbound call is not the same act as placing an outbound one, and a system that stops an agent picking up is enforcing the wrong rule. - A promise falls due on a Sunday. Whether reminders go out on rest days is a policy choice; the point is that it should be a setting somebody chose, not an accident of when the batch happened to run. - A retry is scheduled for 6:55 p.m. and the queue is running late. The window has to be checked at the moment of dispatch, not the moment of scheduling, or the delay itself creates the breach. - The borrower asks not to be called before noon. A per-borrower preference has to beat the campaign default, and it has to survive the next file upload. - A field visit is planned for an address two hours away. Visit windows and calling windows are different rules about different things, and deserve separate settings. **Frequency is the other half of the same rule** Contact hours and contact frequency are usually written about separately and experienced by the borrower as one thing. Six compliant calls inside the window, every day for a week, is not a defensible pattern merely because each call was individually within the hours. Caps belong next to windows: per day, per week, per channel, and counted across channels rather than within each one, because nobody on the receiving end experiences SMS and voice as separate relationships. **Proving it afterwards** Enforcement is only half of what the rule asks for. When a complaint arrives months later, the question is not whether the policy was correct but what actually happened on a particular afternoon. That means every contact carries its timestamp in IST, the window that allowed it, the campaign it belonged to and the outcome it produced, and that all of it can be pulled for one borrower across a year without raising a ticket with engineering. **Five questions worth asking a vendor** - Show me a call that the window blocked, not a report saying none were placed. - Where is the window stored, and who can change it without a deployment? - Is the window evaluated when the touch is scheduled, or when it is dispatched? - Does the frequency cap count across channels, or separately within each? - Can you produce every contact attempt for one borrower for the last twelve months, with times and outcomes? The test for any collections system is one question: can a call that would breach the window even be placed? If the answer involves the word 'shouldn't', the rule is a hope, not a control. ### A DPDP readiness checklist for collections teams (https://attpro.collbox.in/resources/dpdp-collections-checklist) The Digital Personal Data Protection Act treats a delinquent borrower's data with the same seriousness as a customer's. Ten questions your operation should answer. Published 2026-07-20, 3 min read. Collections runs on personal data: phone numbers, addresses, employment details, family references. DPDP makes the lender a data fiduciary for all of it, including whatever sits in an agency's spreadsheets. The exposure is rarely the core system - it is the copies. **The checklist** - Can you list every system and vendor holding borrower personal data for collections? - Is there a lawful purpose recorded for each category of data you process? - Can you honour an erasure request without breaking your evidence obligations - and do you know where the line is? - Are recordings and transcripts on a defined retention schedule, or kept forever by default? - Do field officers' phones hold borrower data outside your control after sync? - Are agency users individually identified, or does the agency share one login? - Is do-not-call state honoured across every channel, or only in the dialer? - Can you produce an access log for one borrower's record across a year? - Do Alternate MetaData vendors process data under contract terms you could show a regulator? - Is there a named grievance owner, and does the escalation path actually work? **The exposure is almost never the core system** Ask where borrower data lives and most teams name the loan management system. The honest answer is longer: the dialer, the recording store, the transcript index, the agency CRM, an Alternate MetaData vendor response cache, three analysts laptops, a WhatsApp group where a supervisor forwarded an address, and the export somebody made for a board pack in March. A data-flow map that stops at the systems with logins is not a map of your risk. **Erasure against evidence** The hardest question on the list is the third one, because two obligations point in opposite directions. A borrower can ask for data to be deleted. A regulator, or a court, can ask you to show what you did and when. These are reconcilable, but only if the distinction was designed rather than discovered during an incident: identifying details and the evidence of conduct are different categories, retained on different clocks, for different reasons. Decide which fields belong to which category before somebody asks, and write the reasoning down while it is still a calm decision. **Retention is a decision, not a default** Recordings and transcripts are the usual offenders, because storage is cheap and deleting things feels risky. Kept forever is still a retention policy, just an unexamined one, and it is the most expensive kind to defend. A schedule per data category, applied automatically, with the deletions themselves logged, turns an open-ended liability into a bounded one. **The agency chain** Work handed to an agency does not hand the obligation over with it. Two questions decide most of the exposure: are agency users individually identified, so that an access log names a person rather than a company, and does the agency keep its own copy of the book after the account is recalled. Shared logins and unreturned copies are the two failures that turn an agency relationship into your incident. **If you cannot answer these yet** Start with the inventory. Every other question on the list is unanswerable until you know where the data is, and most teams find that building the map removes more risk than the controls they were planning to buy, because it surfaces copies nobody had a reason to keep. Teams that answer these from the system - rather than from a document written for the audit - spend less on both compliance and disputes. Retention, consent and access are cheapest when they are properties of the platform, not projects run against it. ### Why your disposition taxonomy is your collections strategy (https://attpro.collbox.in/resources/disposition-taxonomy) Whatever your callers can record is all your analytics can ever know. The disposition list is not admin - it is the resolution of your entire feedback loop. Published 2026-07-05, 3 min read. Every collections conversation compresses into one field: the disposition. If the list offers only 'ringing', 'busy' and 'promised', then every insight downstream - which script works, which cohort needs settlement, which accounts justify field visits - is built on three pixels of information. **Symptoms of a starved taxonomy** - 'Other' is a top-five disposition. - Promises have no date attached, so kept-rate cannot be computed. - Refusals do not record a reason, so hardship never surfaces. - Wrong-number and unreachable are one code, so trace spend is unguided. **What good looks like** A working taxonomy distinguishes contact outcomes (reached, wrong number, unreachable), conversation outcomes (promise with a date, dispute with a category, refusal with a reason, hardship), and system outcomes (voicemail, network failure). Each code should be actionable: if two codes would trigger the same next step, merge them; if one code hides two next steps, split it. **How many codes is the right number** There is no magic count, but there is a test. Every code has to earn its place by changing what happens next. If two codes always lead to the same next action, they are one code wearing two hats, and the split costs you accuracy for nothing. If one code leads to two different next actions depending on what the caller remembers, it is hiding a decision that should have been recorded. Applied honestly, this usually lands an operation somewhere between forty and eighty codes, grouped so that a caller sees a handful of choices at a time rather than a wall of them. **A worked example: splitting not contactable** One code for everything that is not a conversation is the most common and most expensive mistake, because it merges four situations with four different economics. - Ringing, no answer. Cheap to retry, and the right answer is usually a different time of day rather than a different channel. - Switched off or unreachable. Worth retrying for a few days, then worth doubting. - Number invalid or disconnected. Retrying is pure waste. This is the only one of the four where a trace is the correct next step. - Wrong person, number reassigned. Retrying is worse than waste, because the person answering has no relationship with the debt and every reason to complain. Merged, they produce an unreadable contactability rate and an unguided trace budget. Separated, each has an obvious next step, and trace spend goes only where a new number is the thing actually missing. **Changing the list without losing your history** Taxonomies get better by being revised, and revision is where reporting usually breaks. Retire codes rather than deleting them, so last quarter calls still mean what they meant when they were made. Map old codes to new ones explicitly, keep the mapping next to the data, and date the change, so that a year-on-year comparison can state which side of the change it is reading. **Somebody has to own it** A disposition list with no owner drifts. A code gets added for one campaign, another is quietly repurposed because it was the closest thing to hand, and within two quarters the analytics team is reverse-engineering intent from call recordings. Name an owner, review the list on a schedule, and treat an addition the way you would treat a change to a database column, because that is what it is. The payoff is compounding. Flows can branch on real outcomes, analytics can attribute cures honestly, and QA can target exactly the conversations where the code and the recording disagree. ### Anatomy of an AI collections call (https://attpro.collbox.in/resources/anatomy-of-an-ai-collections-call) What actually happens in the seconds between a borrower saying 'haan, bol raha hoon' and a payment link arriving on WhatsApp. Published 2026-06-15, 3 min read. A production AI collections call is a pipeline under a strict clock: the reply must begin within roughly 700 milliseconds of the borrower finishing, or the call feels like a machine and the borrower hangs up. Everything below happens inside that budget, in a loop, for every turn. **The loop, step by step** - Listen: speech recognition streams the borrower's words, in their language, as they speak. - Understand: a language model reads the transcript so far, the account state and the strategy, and decides what to say - or which tool to use. - Act: tools do real work mid-call - record a promise with a date, send a payment link, schedule a callback, mark do-not-call, hand off to a human. - Speak: the reply is synthesised in a natural voice in the borrower's language, with the numbers - amounts, dates - spoken the way people actually say them. - Listen again: if the borrower interrupts, the agent stops and yields. Barge-in is what separates a conversation from an announcement. **What makes it collections-grade rather than a chatbot with a phone number** - The compliance layer sits inside the loop: quiet hours, script boundaries and disclosure rules constrain what the agent may say before it says it. - Every turn is recorded, transcribed and attributable afterwards. - The call ends in a state the flow understands - a disposition - so the next contact is decided by strategy, not by chance. **Where the 700 milliseconds actually goes** The budget is tight because it is shared. Speech recognition needs a moment after the borrower stops to be confident they have stopped rather than paused for breath. The language model needs time to read the conversation so far and decide. Speech synthesis needs time to produce the first audible syllable, though not the whole sentence, because audio can stream. Network transit takes its cut twice. Nothing in that chain can be slow, and the usual failure is not one slow component but four merely acceptable ones. **Language is not a setting, it is the conversation** A borrower who starts in Hindi may finish in English, and many will mix the two inside a single sentence. Treating language as a flag chosen at dial time produces an agent that mishears its own customers. It has to be detected, it has to be allowed to change mid-call, and the numbers have to follow: an amount is spoken differently in Hindi and in Tamil, and a rupee figure read out as bare digits is the fastest way to sound like a machine. **What happens when it goes wrong** It will go wrong, and the design question is what the borrower experiences when it does. Speech recognition returning nothing usable twice in a row, a tool call failing, a borrower who is angry, confused, or says something the script has no branch for: each needs a defined path, and the good path is almost always a human. An agent that cannot hand off gracefully is worse than no agent, because it turns a recoverable conversation into a complaint. **The handoff** A warm transfer is the difference between help and a runaround. The person who picks up should arrive holding the transcript, the account state and the reason for the transfer, so the borrower is not asked to repeat what they have just finished saying. When nobody is free, the honest move is to say so, take a callback time, and keep it. **What to measure** - Time to first response at the ninety-fifth percentile rather than the average. Averages hide exactly the calls that failed. - Interruption handling: how often the borrower had to talk over the agent to be heard. - Containment and escalation read together. Containment alone rewards an agent that refuses to hand off. - Disposition accuracy, sampled against the recording. Everything downstream assumes this number is honest. - Complaint rate per thousand calls, tracked separately from human calls so that a rise is attributable. The result is not a human impersonation. It is a competent, endlessly patient caller that always follows the script boundaries, never has a bad day, and writes perfect notes. ## Glossary - **Allocation**: Assigning an account to a team, agent, agency or field beat, usually by rule (bucket, product, region, capacity) rather than by hand. - **Alternate MetaData**: Finding fresh contact details for a borrower whose numbers have gone dead, under a recorded, purpose-limited reason. - **AMD (answering machine detection)**: Telling a voicemail from a person in the first second of a call so the flow can drop a message and move on instead of burning agent time. - **Auto-cure**: An account closing itself when a payment lands, without anyone marking it: the ledger sees the money and the flow exits. - **Barge-in**: The borrower talking over the agent and the agent stopping to listen. What separates a conversation from an announcement. - **Broken promise**: A promise to pay whose date has passed without money arriving. Re-enters the flow on the branch drawn for exactly that. - **Bucket**: A band of days past due used to group accounts: pre-due, 1-30, 31-60, 61-90, 90+. Strategy is usually set per bucket. - **Calling window**: The hours in which contact is permitted, set per campaign in IST and enforced in the dialer, not the training calendar. - **Campaign**: A book, a strategy and a window, run together. One campaign per lender mandate, product or bucket is typical. - **Consent**: The borrower's recorded permission to be contacted on a channel. Withdrawn consent is a record, not a memo, and is honoured everywhere. - **Cost to collect**: What one contact or one resolved account costs, across people, telecom and tools. The reason the cheap channels carry the volume. - **Cure**: An account returning to current: the overdue amount paid, the case closed with evidence. - **Disposition**: The one-field summary of a contact: reached, promised, disputed, wrong number, hardship. Whatever the list allows is all the analytics can ever know. - **DLR (delivery receipt)**: The carrier's confirmation that a message was delivered, read or failed. Each one is a signal the flow can branch on. - **DLT (Distributed Ledger Technology, TRAI)**: TRAI's registry of senders and SMS templates. An unregistered template cannot be dispatched from the platform. - **DNC (do not call)**: A borrower's request not to be contacted, on one channel or all. Honoured tenant-wide and platform-wide. - **DPD (days past due)**: How many days an instalment is overdue. The clock behind every bucket. - **DPDP Act**: India's Digital Personal Data Protection Act, 2023. Makes the lender the data fiduciary for borrower data and sets rights to access, correction and erasure. - **DRA (Debt Recovery Agent)**: The IIBF certification RBI expects of people who recover on a lender's behalf. Every caller and field officer on the floor holds it. - **Escalation ladder**: The cadence from a pre-due reminder to a doorstep visit, in tiers, only reaching the expensive end when it has to. - **Evidence trail**: The recording, transcript, receipts, geo-tag and disposition a contact leaves behind, written as it happens rather than reconstructed later. - **Fair Practices Code (RBI)**: RBI's conduct expectations for lenders and their agents: reasonable hours, no harassment, disclosure, grievance handling. - **Field visit**: A doorstep contact by a field officer, allocated from the flow and captured with location, time and outcome. - **Flow**: The recovery strategy drawn as a graph: contact, wait for what happens, branch on the outcome, escalate. Run per borrower, continuously. - **FOS (field officer / feet on street)**: The person who visits. On this platform, their day is allocated on the phone and returns as data. - **Frequency cap**: The most times a borrower may be touched in a day or a window, across channels. Protects borrowers from pile-on and lenders from complaints. - **Hardship**: A recorded outcome, not an inconvenience: the borrower cannot pay as agreed and the account routes to revised arrangements a human can approve. - **Hash-chained audit log**: An audit log where each entry carries the hash of the one before, anchored with a Merkle root, so a changed record breaks the chain and shows up. - **Legal hold**: Freezing retention and erasure on an account because of a dispute or proceeding. Itself audited. - **LMS (loan management system)**: The lender's system of lending record. The platform sits beside it as the system of collections record. - **NACH**: The NPCI mandate rail for recurring debits. One of the payment options the portal and links offer. - **NPA (non-performing asset)**: An account overdue past the regulatory threshold, usually 90 days. Slippage into NPA is what early-bucket work prevents. - **OBD (outbound dialling, voice broadcast)**: A recorded voice message with a keypress to pay or reach an agent. Scales voice contact cheaply. - **PTP (promise to pay)**: A commitment to pay an amount by a date, captured on a call or a visit and tracked to the day. - **Quiet hours**: The hours outside the calling window. On this platform a call in quiet hours is not flagged afterwards; it is never placed. - **RCS**: Rich Communication Services: branded, interactive messages on supported Android phones, falling back to SMS. - **Resolution rate**: Accounts cured in a period as a share of the book worked. The headline number a head of collections reports. - **Roll rate**: The share of accounts that move from one bucket to the next worse one in a month. Flow rate is the reverse. - **SARFAESI**: The statutory process for recovering against secured property in India, with strict notice periods. - **Settlement**: An approved one-time or restructured payment that closes an account for less than the full outstanding. - **Tenant**: One lender's isolated space on the platform: its own database schema, users, credentials and evidence. - **Warm transfer**: The AI agent handing a live call to a person with the transcript and account state already in front of them. ## Frequently asked Q: What exactly is attpro? A: An operating system for collections. You upload your delinquent book, describe your recovery strategy once as a visual flow, and the platform contacts every borrower across voice, WhatsApp, SMS, email, field and a self-service portal - then feeds every outcome back into the strategy to decide the next step. Money and evidence come out of the same loop. Q: Who is behind it? A: ATTPRO Business Solutions, a debt management company with twenty-five years in Indian collections, 325 people on the floor and in the field across eight cities, and a live book of asset reconstruction companies, NBFCs and lenders. The platform runs that operation first; lenders licence it to run theirs, or allocate a portfolio and let the floor work it. Q: Do you only sell software, or can you run the collections too? A: Both. Managed recovery: you allocate the portfolio and our telecalling, digital and field teams work it on the platform, priced on recovery. Platform licence: your team runs on the software in your own tenant with your own credentials. Hybrid: your team on early buckets, ours on the hard ones, in one tenant with one reporting line. Q: Who is it built for? A: Indian lenders and the teams that collect for them: NBFCs, banks, fintech lenders, ARCs and recovery agencies. The defaults assume Indian lending - DPD buckets, lakh and crore, UPI and NACH, RBI conduct expectations, ten Indian languages plus Hinglish. Q: Does it replace our LMS or core banking system? A: No. Your LMS stays the system of lending record. attpro sits beside it as the system of collections record: a nightly export over SFTP is enough to start, and REST APIs with webhooks carry same-day state when you want it. Results flow back to your MIS. Q: How long does it take to go live? A: Days, not quarters. Onboarding is a file-mapping session for your LMS export, provider credential setup, and a first flow built together. We recommend starting with one cohort and measuring against its own history. Q: Can an AI agent really hold a collections call in Hindi? A: Yes - a live, interruptible conversation, not an IVR. The agent listens through interruptions, records promises with dates, sends payment links mid-call, and hands off to a human with full context when judgement is needed. The demo includes a live call to a test number in the language you choose. Q: How is borrower data protected? A: Each lender's data lives in its own database schema, in India, encrypted in transit and at rest. Provider credentials are yours, support access is time-boxed and audited, and retention, erasure and legal hold are system properties built for the DPDP Act. The security page states the full posture, including what is certified and what is roadmap. ## Changelog **2026-08-29 - Trust Center, legal documents and the public cadence planner** [platform]: Trust Center with controls, certifications, sub-processors and documents available under NDA. Privacy, terms, grievance and disclosure rewritten with numbered sections, effective dates and a change log. The escalation-ladder planner is public: set cycle, product, lender, ticket, region and team and watch the cadence resolve. **2026-07-31 - Voice realism wave** [voice]: Heuristic turn detection tuned for Hindi and Indian English so the agent does not interrupt a pause. Self-hosted noise cancellation on the borrower's side of the call. Sentiment-adaptive delivery and cross-call memory, per agent, off by default. **2026-06-23 - Backchannels, pronunciation and mid-call language switch** [voice]: Filler words so there is no dead air while the agent thinks, with per-language defaults. A pronunciation dictionary and boosted keywords for lender names and product terms. The borrower can switch language mid-call and the agent follows. Break types and break tracking for the live-transfer console. **2026-06-22 - Real-time, interruptible AI calls** [voice]: Live conversation with barge-in on every AI voice call, in Indian languages. Per-tenant speech and voice provider keys. Test calls from the browser before an agent goes live. **2026-06-07 - AI calls and voice broadcasts as flow steps** [flows]: An AI-call node that branches on the actual disposition or connection outcome. A voice-broadcast node that branches on keypress or no input. Both park the flow and resume when the call reports back; timeouts take the branch you drew. **2026-06-06 - Email channel** [channels]: Email templates with subject and reply-to, sent from the flow and branching on delivered, opened, clicked, bounced and spam signals. **2026-06-05 - Human queue, Alternate MetaData and channel signals in the flow** [flows]: A human-queue node that waits for the agent's disposition or an SLA breach. Alternate MetaData and nominee-trace nodes that resume when results land. Delivery and read receipts from SMS and WhatsApp advance waiting flows. **2026-06-04 - Flow builder rebuilt** [flows]: Automatic layered layout, labelled outcome ports on every node, a searchable step rail with hover explanations. An active/inactive runtime switch on published flows. Tenant-shared templates and a one-click fix for validator findings. **2026-05-30 - Account self-service, in-app help and undo** [platform]: Profile, password change, MFA reset and password-reset links for platform users. An Info Center with page-by-page help in English and Hindi. Undo on reversible borrower actions: promises, callbacks, pay links, hardship, settlement offers. **2026-05-28 - Upload wizard and file master** [platform]: A five-step upload: file, map, campaign, preview, result, with saved column mappings and a dry run. One active working file per campaign, with swap and retirement handled for you. Bulk edit in a spreadsheet grid with a reason on every save. **2026-05-27 - Borrower 360 and AI intelligence dashboards** [analytics]: One borrower record with fifteen one-click actions, conversation prep in ten Indian languages, and cross-loan grouping. Cohort views: risk distribution, predictive cures, settlement opportunity, contact-time heatmaps, risk migration. **2026-05-14 - General availability** [platform]: Multi-tenant platform, voice, messaging, flows, field app, payments, analytics, compliance and the ops console all live. ## Open roles - Trainer, Collections Conduct and Product (https://attpro.collbox.in/company/careers/trainer-collections-conduct) - Quality and training, Pune/Noida, Full-time, 3 to 7 years: Induct new callers and officers, run the refresher cycle on RBI conduct, and teach the platform as a tool rather than a screen. - Data Analyst, Collections (https://attpro.collbox.in/company/careers/collections-data-analyst) - Digital and portfolio, Mumbai/Chennai/Noida, Full-time, 2 to 5 years: Turn the platform's data into the lender's monthly review and the floor's daily targets: roll rates, cure attribution, channel economics, forecast versus actual. - Voice AI Engineer (https://attpro.collbox.in/company/careers/voice-ai-engineer) - Platform engineering, Pune/Mumbai, Full-time, 3 to 7 years: Make the AI agent better at Hindi, Tamil, Marathi and Hinglish collections calls: speech, turn-taking, prompts, tools, evaluation against real recordings. - Software Engineer, Platform (https://attpro.collbox.in/company/careers/software-engineer-platform) - Platform engineering, Pune/Mumbai, Full-time, 3 to 8 years: Build the operating system the floor runs on: flows, channels, payments, evidence. Python and TypeScript, Postgres, a small team with strong opinions. - Product Manager, Collections OS (https://attpro.collbox.in/company/careers/product-manager-collections-os) - Platform engineering, Mumbai/Pune, Full-time, 5 to 10 years: Own the platform roadmap with the floor downstairs as your first customer: what ships next in voice, flows, channels and evidence, in what order, and why. - QA Automation Engineer (https://attpro.collbox.in/company/careers/qa-automation-engineer) - Platform engineering, Pune/Chennai, Full-time, 3 to 6 years: Build the automated test estate for the collections OS: API and integration suites, end-to-end flows through the web and field apps, and the release checklist a BFSI customer can audit. - Mobile Engineer, FOS App (React Native) (https://attpro.collbox.in/company/careers/mobile-engineer-react-native) - Platform engineering, Pune/Mumbai, Full-time, 3 to 7 years: Own the FOS App by ATTPRO: offline-first visit capture, geo-tagging, receipts and sync, on Expo React Native for Android and iOS, used by hundreds of field officers every day. - Frontend Engineer, Next.js (https://attpro.collbox.in/company/careers/frontend-engineer-nextjs) - Platform engineering, Pune/Mumbai, Full-time, 3 to 7 years: Build the operator surfaces of the collections OS: the flow builder canvas, the telecaller console, the borrower 360, the dashboards. Next.js, TypeScript strict, Tailwind, React Flow, data grids. - DevOps Engineer, Collections OS (https://attpro.collbox.in/company/careers/devops-engineer) - Platform engineering, Pune/Mumbai, Full-time, 4 to 8 years: Run and harden the platform: Docker-based deploys, Postgres and Redis operations, encrypted backups with restore drills, CI, alerting, and the move from a single host to a multi-node Indian-region cloud. - Senior Python Developer, Collections OS (https://attpro.collbox.in/company/careers/senior-python-developer) - Platform engineering, Pune/Mumbai, Full-time, 5 to 10 years: Own the backend of the collections operating system: the flow engine, channel adapters, payments reconciliation and the evidence ledger, in Python on FastAPI, Postgres and Celery. - Client Onboarding and Delivery Lead (https://attpro.collbox.in/company/careers/client-onboarding-lead) - Client delivery, Mumbai/Noida, Full-time, 4 to 8 years: Take a lender from signed agreement to first cured account: the file-mapping session, provider credentials, the first flow, the first month's review. - Site Manager, Collections (https://attpro.collbox.in/company/careers/collections-manager-site) - Collections floor, Noida/Pune, Full-time, 8 to 12 years: Run a stationed site end to end: floor and field, capacity, conduct, lender relationships and the P&L, on the platform. - Digital Portfolio Manager (https://attpro.collbox.in/company/careers/digital-portfolio-manager) - Digital and portfolio, Mumbai/Noida, Full-time, 4 to 8 years: Own the strategy for a lender's book on the platform: segmentation, the escalation ladder, channel mix and cost to collect, measured every day on the dashboard. - Field Supervisor (https://attpro.collbox.in/company/careers/field-supervisor) - Field, Mumbai/Chennai, Full-time, 5 to 10 years: Plan beats, allocate officers, watch coverage and outcomes on the dashboard, and own conduct in the field for a city. - Field Officer (FOS) (https://attpro.collbox.in/company/careers/field-officer-fos) - Field, Mumbai/Pune/Chennai/Noida, Full-time, 1 to 5 years: Work a beat on the FOS app: today's allocations, the script, offline capture of the visit, receipts on the spot. Two-wheeler, auto, personal loan and LAP. - Quality Reviewer, Calls and Conduct (https://attpro.collbox.in/company/careers/qa-reviewer-collections) - Quality and training, Chennai/Mumbai, Full-time, 2 to 5 years: Listen to the sampled calls, human and AI, score conduct and disposition accuracy, and turn what you find into training and prompt feedback. - Team Leader, Telecalling (https://attpro.collbox.in/company/careers/team-leader-telecalling) - Collections floor, Chennai/Pune/Noida, Full-time, 4 to 8 years: Run a pod of 12 to 15 callers on the platform: queues, dispositions, breaks, QA samples and the day's numbers, with complaints as the metric you are judged on as much as cures. - Senior Telecaller, Hard Bucket and Settlements (https://attpro.collbox.in/company/careers/senior-telecaller-hard-bucket) - Collections floor, Mumbai/Chennai, Full-time, 3 to 6 years: Negotiate 60+ DPD accounts, settlements and restructures, with warm transfers from the AI agent landing on your desk with the full transcript. - Telecaller, Collections (https://attpro.collbox.in/company/careers/telecaller-collections) - Collections floor, Chennai/Mumbai/Pune/Noida, Full-time, 0 to 3 years: Talk to borrowers in their language, capture a promise with a date, and hand the hard cases to the platform and your team lead. Recording on every seat, calling windows enforced for you.