Lending

The applicant's file, from the source.

Identity, income streams, assets, liabilities and two years of transactions behind one access token — four parallel calls instead of a document upload, an OCR pipeline and a manual review queue. Forward-looking cash flow and anomaly signals sit on the same key.

who this is for

Statements are a terrible input.

Lenders and credit teams replacing PDF statements with an API call

A PDF bank statement is slow to collect, easy to alter, expensive to parse and stale by the time an analyst opens it. Every lending team eventually builds the same escape hatch: read the account directly, and reserve human review for the files that actually need it.

What that requires is not one endpoint but a coherent set — account-holder identity to match against the application, income detected from cadence rather than claimed, assets and liabilities as the institution reports them, and enough transaction history to run whatever affordability arithmetic your credit policy specifies.

All of it hangs off one fc_at_… token here, in normalized shapes that do not change when the provider underneath does — which matters when your underwriting model has to keep working through an aggregator migration.

what you'd call

The endpoints this actually uses.

Underwriting reads wide rather than deep: several endpoints once per applicant, rather than one endpoint continuously.

Endpoints used by lending and underwriting integrations
POST/v1/identity/getNames, emails, phones and addresses on the account
POST/v1/income/getIncome streams with cadence and confidence
POST/v1/assets/getAssets, liabilities and net worth in one response
POST/v1/liabilities/getCards, student loans and mortgages with APR and terms
POST/v1/accounts/balance/getBalances refreshed at decision time
POST/v1/transactions/getDate-range history for affordability arithmetic
POST/v1/ai/cashflowForward projection over a 7–120 day horizon
POST/v1/ai/fraud-riskAnomaly signals with a low/medium/high verdict
POST/v1/items/refreshPull fresh data before a decision is finalised

in code

What the integration looks like.

The file first, assembled in parallel because the calls are independent. Then the forward-looking signals you would run over it.

tsapplication-file.ts
import { FeelConnect } from "@feelconnect/node"; const fc = new FeelConnect({  apiKey: process.env.FEELCONNECT_SECRET_KEY!,  baseUrl: "https://connect.feels.money/v1",}); // One applicant file, assembled from the account rather than uploaded.export async function buildApplicationFile(accessToken: string) {  const [identity, income, assets, liabilities] = await Promise.all([    fc.identity.get({ access_token: accessToken }),    fc.income.get({ access_token: accessToken }),    fc.assets.get({ access_token: accessToken }),    fc.liabilities.get({ access_token: accessToken }),  ]);   return {    // Names, emails, phones and addresses as the institution holds them —    // the check that a stated identity matches the funding account.    holder: identity.identity,     // Detected streams with cadence and confidence, not a single number.    income: income.income_streams,     // total_assets, total_liabilities and net_worth are computed for you.    position: {      assets: assets.total_assets,      liabilities: assets.total_liabilities,      netWorth: assets.net_worth,    },     // Cards, student loans and mortgages with their APR and term detail.    obligations: liabilities.liabilities,  };}
tsrisk-signals.ts
// Forward-looking signals on the same connection.const { forecast } = await fc.ai.cashflow({  access_token: accessToken,  horizon_days: 90,}); // Anomaly detection also runs in payload mode, so it can score a file// you assembled from an aggregator you already pay for.const { signals, overall_risk } = await fc.ai.fraudRisk({  access_token: accessToken,}); if (overall_risk === "high") {  await routeToManualReview(signals);} // A 24-month transaction history behind the same token, for the// affordability arithmetic your credit policy actually specifies.const history = await fc.transactions.get({  access_token: accessToken,  start_date: "2024-07-01",  end_date: "2026-07-01",  options: { count: 500, offset: 0 },});

what you get

Mechanisms, in the order you would meet them.

  1. Identity as the institution holds it

    The names, emails, phones and addresses on the account — the check that the person applying is the person the funding account belongs to.
  2. Income as streams, not a number

    Detected from cadence and stability, with confidence attached, so your policy can distinguish a steady salary from a volatile one rather than averaging them together.
  3. Assets and liabilities in one call

    /v1/assets/get returns totals and net worth computed across every connected account; /v1/liabilities/get adds APR and term detail per obligation.
  4. Forward-looking, not just historical

    Cash-flow forecasting over a 7 to 120 day horizon, and anomaly signals that also run in payload mode against data you already hold.
  5. Your provider relationship

    On Enterprise, connections run under your own aggregator agreement, which is usually the only arrangement a regulated lender's compliance team will sign.
  6. An auditable trail

    Every request is logged with its path, status, latency and request id, and console actions are recorded in an org-scoped audit log with actor, target and source IP.

questions

Straight answers.

Underwrite from the account, not the attachment.

Assemble a full applicant file against the sandbox today — identity, income, assets, liabilities and 24 months of history — and see whether the shapes fit your credit policy before anyone signs anything.

The sandbox needs no approval and no card. You can have the shapes in front of you in a few minutes and decide from there.