Skip to content
PFSIFinancial Intelligence

Developers

Intelligence Designed for Integration.

Explore the technical concepts behind integrating contextual financial intelligence into institutional systems. This page is written for technical decision-makers and engineering teams — and it labels its examples honestly: everything here is conceptual.

API Architecture

A conceptual institutional request lifecycle.

  1. STEP 1

    Authenticated institution

  2. STEP 2

    Authorized request

  3. STEP 3

    Context validation

  4. STEP 4

    Intelligence processing

  5. STEP 5

    Explainable response

No stage is optional. A request that cannot establish the institution's identity, its authorization, or the validity of its financial context does not reach intelligence processing.

Example API Interaction

The shape of an explainable response.

Conceptual example only. Not an official PFSI API contract or endpoint.

The figures are the User B scenario from the homepage — $2,000 starting balance, $1,950 of obligations, $50 projected before income — expressed as a structured response. The explanation field is part of the contract concept: intelligence without its reasoning is not delivered.

Illustrative JSON responseSynthetic
{
  "scenario_id": "demo_001",
  "currency": "CAD",
  "starting_balance": 2000,
  "days_until_income": 18,
  "upcoming_obligations": 1950,
  "projected_pre_income_balance": 50,
  "signal": "elevated_near_term_pressure",
  "explanation": "Scheduled obligations consume most available funds before expected income.",
  "data_type": "synthetic_example"
}

* Illustrative scenarios using fictional financial information. Not live customer data or a production PFSI assessment.

Integration Principles

Six principles every integration is designed around.

  1. 01

    Authorization and institutional identity

    Every integration begins with an authenticated institution and a defined authorization scope. Requests outside that scope are not processed — identity and permission are prerequisites, not features.

  2. 02

    Consent and permitted use

    Financial intelligence is processed only for the purposes it was authorized for. The permitted purpose travels with the request and constrains what the platform will compute and return.

  3. 03

    Tenant separation

    Each institution's data and intelligence are isolated within its own tenant boundary. Separation is architectural — enforced by the platform's structure, not by convention.

  4. 04

    Traceable intelligence outputs

    Responses carry their reasoning: the signal, the inputs behind it and the assumptions applied. An institution can audit any output back to its basis.

  5. 05

    Versioned integration contracts

    Integration contracts are versioned so institutional systems can adopt changes deliberately, validate against them and roll forward on their own schedule.

  6. 06

    Test environments and validation

    Institutions evaluate behaviour in test environments with synthetic data before any production consideration — the same discipline this page applies to its own examples.

Developer Resources

Documentation, on request.

Resource links are activated only when the corresponding verified resources exist. Until then, technical documentation is provided directly to institutions in evaluation.

Request Technical Documentation

  • API documentation

    In preparation — available to institutions during technical evaluation.

  • Integration guides

    In preparation — published alongside the documentation set.

  • Data schemas

    In preparation — shared under evaluation agreements.

  • Security architecture

    Reviewed during the security evaluation stage of an institutional engagement.

  • Changelog

    Begins with the first versioned integration contract.