Plugging into Borrow Money's lender ping-tree and offer flow

Three things matter when you wire this app into something else: who the applicant said they were, which lenders in its ping-tree picked the lead up, and the terms the borrower walked away with. Per its Play Store listing, the app brokers loan requests for amounts between $100 and $2,500 with repayment windows from 65 days to 24 months, an APR band of 5.99% to 35.99%, and a US-only audience that has to be 18 or older with an active checking account and at least $1,000 a month in income. That product surface is what an integrator actually touches.

The app describes itself, in its own material disclosure, as neither a direct lender nor a broker — only a connector that pushes a borrower record into a network of independent licensed lenders and lets them respond. That framing matters for the integration. The data of interest is split between the applicant's own submission, the per-lender match decision that comes back, and the signed offer that lands once the borrower accepts.

Where the borrower's data lives inside the app

How we'd actually reach the data

Three routes apply here, and the build usually centres on the first.

Authorized interface integration with a consenting borrower account. We install the app in a controlled environment, observe the calls between the app and its backend during a real submission with a consenting test applicant, map the application, match and accept calls, and re-implement them as a clean API your code can call. Reach is full: applicant submission, the ping-tree match response, lender ids and offer terms, the signed-offer artifact. Effort sits in the middle. Durability depends on how often the vendor revises its backend — see the engineering notes.

User-consented session access to the borrower's own account. Once an applicant has submitted, the app retains application state and matched offers on its backend. With a consenting borrower's credentials we replay the session against the status endpoints to pull the offer book and the application's progress. Reach is narrower — one borrower per consent — but the route stays useful for ongoing status sync after the initial integration is live.

Lender-side bridge. If your client is one of the licensed lenders that participates in the app's ping-tree, the cleanest delivery is the direct lead-delivery integration the lender already has with the aggregator. We can wire that side instead, normalising the leads into your underwriting stack. Different shape of work, often the right one for a lender client.

For a downstream consumer of the app's offer surface, route one carries the build, with route two added for status sync. For a lender client, route three replaces both.

Engineering notes from working with this app's surface

Several things shape the build here, and we account for them inside the engagement rather than as preconditions.

• Ping-tree variability. The match response is not one fixed schema; the fields that come back depend on which lender in the tree picked up the lead and at what position. We normalise across the variants seen during the build and flag the long-tail cases so downstream code does not crash on a new lender shape.
• State usury and eligibility. The 5.99% to 35.99% APR band assumes a lender that can actually serve the borrower's state. New York, New Jersey, Massachusetts and Connecticut among others narrow that band sharply or push lenders out entirely. We map the effective offer surface against state-by-state legality during the build, so the integrated output is state-aware before it lands in your code.
• TCPA and consent artifact capture. A lead-aggregator integration that drops the TCPA, credit-pull and data-share flags is the one that gets a lender client into trouble later. The build captures and persists the consent payload — values plus timestamps — as a first-class part of the application record, not an afterthought.
• Banking-instrument hygiene. Routing and account numbers come through the submission form to the app's backend. We tokenise on entry, keep the raw numbers off our own logs, and let downstream code reference the token rather than the pair.
• Drift watch. When the vendor revises the front end or the backend, the surface shifts. The delivered build includes a small re-checker that self-tests against a known submission shape and raises a clear failure when something has moved.

Where the legal weight actually lies for this app

The app's own material disclosure already states it is neither a direct lender nor a broker, only a connector to independent licensed lenders. That framing puts most of the legal weight on three things.

FTC lead-generator guidance. The FTC has been explicit, including in the 2022 settlement against a major lead generator, that an aggregator has to disclose to consumers that their data is being sold downstream, get express consent for the sharing, and verify the identity of the businesses on the receiving end. The re-implemented application path keeps those disclosures intact rather than smoothing them out.

State usury caps and small-dollar rules. The advertised APR band only holds in states that allow it. A handful narrow it well below the upper end or prohibit the product entirely; the integration treats state-by-state legality as a first-class input rather than a post-hoc filter.

TCPA on downstream outreach. If a lender plans to call or text the applicant after submission, the consent record we capture is what protects that call later. The integrated record stores that consent payload with its timestamp.

The CFPB Payday Lending Rule's payment-withdrawal protections (the two-unsuccessful-attempts limit) sit in the background. The agency has publicly signalled it will not prioritise enforcement of that rule for the moment, per its 2025 announcement, but the protections remain on the books and several state attorneys general have been picking up some of the slack, so the integration keeps the relevant fields modelled. The CFPB Personal Financial Data Rights piece under §1033 is a forward-looking question, not a current basis — it was finalised in 2024, then enjoined by an Eastern District of Kentucky court in October 2025 and is back in agency reconsideration, so the page does not treat it as governing law for this integration. The dependable basis here is the borrower's own express consent at the moment of submission.

Compliance posture on our side: NDAs where the client wants them, signed authorisation from the consenting borrower whose account we work against, data minimised in transit and at rest, full log of what was read and when.

The handover at the end of the cycle

When the build closes, you get:

• An OpenAPI 3 specification covering application-submit, match-response, status-poll and offer-accept, modelled against the app's actual fields rather than a stylised version.
• The protocol and auth-flow report — transport, tokens, how the session is established, how it refreshes, how errors surface. Written so an engineer who never touched the app can hold the spec in one hand and the report in the other.
• Runnable source in Python or Node.js — your pick — with the submission, match and status-poll calls already wired against the real surface.
• A normalisation layer that turns the ping-tree match response into a stable, state-aware offer object your code can read without caring which lender produced it.
• Automated tests that run against a consenting test account during the build, plus the re-checker mentioned above so backend drift does not fail silently.
• Interface documentation — request/response shapes, edge cases, consent payloads — written for whoever has to keep the integration alive.
• Compliance and data-retention guidance specific to the FTC lead-gen, state-usury and TCPA stack above, including the consent payload model.

How the application + match call actually looks

Field set is illustrative; the exact shape is confirmed during the build.

POST /v1/applications
Authorization: Bearer <session-token>
Content-Type: application/json

{
  "applicant": {
    "first_name": "Casey",
    "last_name": "Morgan",
    "dob": "1989-07-14",
    "ssn_last4": "0142",
    "address": {"state": "TX", "zip": "75201"}
  },
  "employment": {
    "employer_name": "Acme Logistics",
    "monthly_income_usd": 2350,
    "pay_frequency": "biweekly"
  },
  "banking": {
    "routing": "111000025",
    "account_token": "tok_8c3...",
    "type": "checking"
  },
  "loan_request": {
    "amount_usd": 800,
    "purpose": "auto-repair"
  },
  "consent": {
    "tcpa":              {"granted": true, "ts": "2026-05-29T14:02:17Z"},
    "soft_credit_pull":  {"granted": true, "ts": "2026-05-29T14:02:17Z"},
    "share_with_network":{"granted": true, "ts": "2026-05-29T14:02:17Z"}
  }
}

Match response, after normalisation:

{
  "application_id": "app_8f...",
  "state_legality": "ok",
  "matches": [
    {
      "lender_id": "lndr_42",
      "offer": {
        "amount_usd": 800,
        "apr_pct": 26.4,
        "term_months": 12,
        "monthly_payment_usd": 75.12,
        "signed_offer_url": null
      }
    }
  ],
  "ping_tree": {"position_won": 2, "lenders_pinged": 7}
}

The signed-offer artifact appears once the borrower accepts in the app. The integration polls the status endpoint until that happens, then captures the signed document into your store.

How sticky the app's surface tends to be

Small-dollar lending aggregators sit in a category that moves. The vendor adds and drops lenders from the ping-tree as state licensing changes and as commercial terms shift; the front end churns more slowly. In practice the application-submit and status-poll surfaces stay put for months at a time, while the match-response shape is what moves first, because it follows whichever lender wins the ping. The build is centred on the stable surfaces and isolates the volatile one behind the normalisation layer, so a new lender shape does not bring the whole client down.

Listing screenshots we worked from

Pulled from the Play Store listing on 2026-05-29 — the same screens an integrator walks through with a consenting test applicant.

What was checked, and where it came from

Cross-checks on 2026-05-29: the app's Play Store listing for product description, loan range, repayment band, APR band and the advertised eligibility floor; the FTC's published guidance on lead-generation businesses for the consent and disclosure posture; the CFPB's Payday Lending Rule resource page for current enforcement footing; and the CFPB's Personal Financial Data Rights reconsideration page for the §1033 status used above.

• Borrow Money: Get Instant Cash — Google Play listing
• FTC — Lead generation: when the "product" is personal data
• CFPB — Payday Lending Rule
• CFPB — Personal Financial Data Rights Reconsideration

Reviewed 2026-05-29 by the OpenBanking Studio integration desk.

Other small-dollar apps that show up in the same integrations

• Brigit — cash-advance without a credit pull; integration value sits in the advance ledger and the linked checking-account telemetry behind its underwriting.
• Dave — cash-advance plus a separate checking product, with a tip-based fee surface; integrators want the advance ledger and the linked-account state.
• Earnin — earned-wage access against worked-but-unpaid hours, so the relevant surface is the timesheet-linked advance history rather than a loan-match record.
• MoneyLion — Instacash advances, a credit-builder loan and a banking surface; integrations usually want the advance ledger, the loan record and the membership status together.
• Klover — cash-advance whose underwriting reads bank-account telemetry; the data of interest is the advance history alongside the points/rewards ledger.
• Albert — instant advance plus an advisor service; the integration surface is the advance and the linked checking-account telemetry, close in shape to MoneyLion.
• FloatMe — smaller, fixed-size advances against direct-deposit history; integration value is the advance record and the bank-link side.
• Lenme — peer-to-peer lending marketplace rather than a single-lender app; the data of interest is loan listings, bids and funded-loan records, more lender-side than borrower-side.

These are independent products of their respective companies, listed only to map the integration neighbourhood around the app on this page.

What integrators ask before briefing us on this app

What does the borrower's record actually contain by the time it reaches a lender?

Identifying details (name, address, DOB, last four of the SSN), the employment and monthly-income figures the applicant submitted, a routing and account-number pair tied to a checking account, the loan amount and purpose, and the three consent flags (TCPA, soft credit pull, share with the lender network). The exact shape varies with which lender in the ping-tree picks the lead up, so the build normalises across the variants observed.

Can we see which lender in the ping-tree won the application, and on what terms?

Yes. The match response carries the matched lender id, the offer amount, the APR, the term and the monthly payment, plus the ping-tree position the winning lender held. We surface these as a structured offer object and keep the raw response alongside it for audit.

How does the advertised $100 to $2,500 range and 5.99% to 35.99% APR band interact with state usury caps?

The band only holds in states whose small-dollar rules allow it. New York, New Jersey, Massachusetts, Connecticut and a handful of others narrow it sharply or push the lender out of the state. The integration tags every match with a state-legality view so downstream code does not have to do that mapping on its own.

How do we keep the consent record clean enough that a downstream lender can rely on it later?

The TCPA, credit-pull and data-share flags are captured with their timestamps as a first-class part of the application record, persisted alongside the lead, and available to any consuming system through the same API your integration uses to read offers.

Next step

Cycle is one to two weeks from kick-off. Pricing settles either as a source-code delivery from $300 — paid after we hand it over and once you are satisfied with what runs — or as a pay-per-call hosted endpoint with no upfront fee, where you only pay for calls you actually make. Either way the next step is short: a few lines on the app and what you want out of its data. Get in touch and we will come back with a scope and a date.