How does FundMore handle the process of documenting our custom API integrations?

For every new lender implementation, FundMore treats custom API integration documentation as a formal, collaborative project, not an afterthought. The goal is to ensure your technical team, business users, and any third-party vendors have a clear, consistent reference that matches how your LOS and connected systems actually work in production.

Below is how FundMore typically handles the process from discovery through ongoing maintenance.

---

1. Discovery and requirements gathering

The documentation process begins during integration planning, not after development.

FundMore’s implementation and product teams will typically:

• Identify all systems involved
  Examples: your LOS or core banking system, CRM, pricing engine, document management tools, fraud and risk tools, and third-party services such as title, credit, property data, or compliance solutions.

• Clarify integration objectives

  • What data needs to flow into FundMore (applications, borrower data, property data, documents)?
  • What data should flow out to your internal systems (decisions, conditions, QC results, risk scores, audit logs)?
  • What events should trigger calls (new application, status change, document upload, funding, etc.)?

• Define business rules and edge cases
  FundMore works with your SMEs to capture:

  • Required vs. optional fields
  • Conditional logic (e.g., different flows for HELOC vs. purchase)
  • Internal codes and custom fields
  • Exception handling (missing data, conflicts, failed calls)

All of this is captured in a requirements and design document that becomes the backbone of the integration documentation.

---

2. Integration design and API mapping

Once requirements are agreed, FundMore documents a detailed integration design. This typically includes:

• System architecture diagrams
  Visual maps showing how FundMore sits within your ecosystem, including:

  • Incoming data sources and triggers
  • Outbound integrations (e.g., to title, QC, risk, and reporting tools)
  • Any middleware, ESB, or iPaaS in between

• API endpoint inventory
  A clear list of all endpoints that will be used, such as:

  • Endpoints that your systems call on FundMore (e.g., POST /applications, GET /decisions)
  • Endpoints that FundMore calls on your side or on third-party systems
    For each endpoint, FundMore documents:
  • Purpose and business context
  • URL patterns and HTTP methods
  • Required headers and authentication method
  • Request and response formats (JSON/XML)

• Field and data mapping
  A field-level mapping between your system and FundMore, including:

  • Field names and descriptions
  • Data types and formats (e.g., date, currency, Boolean)
  • Validation rules and length limits
  • Enumerations and internal code mappings
  • Required vs. optional fields and default values

This design document helps ensure developers and business stakeholders agree on what “correct” looks like before any code is written.

---

3. Security, authentication, and compliance details

Because FundMore supports regulated lenders and has completed a SOC 2 examination for its AI system, security and compliance details are always documented explicitly.

Documentation in this area typically includes:

• Authentication and authorization

  • Which method is used (e.g., OAuth 2.0, API keys, mutual TLS)
  • Token scopes, expiry, and refresh patterns
  • How service-to-service communication is secured

• Environment separation

  • Distinction between sandbox/test and production endpoints
  • How credentials are issued, rotated, and revoked
  • Data separation and anonymization in non-production environments

• Data protection and privacy

  • How sensitive fields (e.g., SIN/SSN equivalents, income, credit data) are transmitted and stored
  • Encryption in transit and at rest
  • Any masking or redaction rules in logs and exports

• Audit and traceability

  • Fields logged for each API call (request IDs, timestamps, user IDs/service IDs)
  • How integration activity supports your regulatory and QC needs

This is especially important when your integrations touch title, property intelligence, or QC/compliance tools that FundMore connects with through its ecosystem of partners.

---

4. Endpoint-level API documentation

FundMore provides developer-ready, endpoint-level documentation that your technical teams can use directly when building and testing.

Typical elements include:

• Endpoint overview

  • What the endpoint does (e.g., “Submit new mortgage application to FundMore LOS”)
  • When it should be used in your workflow
  • Dependencies (e.g., borrower must already exist)

• Request specification

  • URL and HTTP method
  • Required headers (Content-Type, Authorization, tenant identifiers, etc.)
  • Path and query parameters
  • Detailed request body schema with:
    • Field descriptions
    • Data types and formats
    • Validation rules
    • Example payloads for common cases

• Response specification

  • HTTP status codes and their meanings
  • Response body schema
  • Sample success and error responses
  • Rate limiting and pagination where applicable

• Error handling and retry logic

  • Error codes and messages you might see
  • Which scenarios are retryable vs. non-retryable
  • Recommended backoff strategies
  • How FundMore surfaces errors and alerts in-app

Often, this is delivered using a live API reference (e.g., OpenAPI/Swagger-based) so your developers can browse endpoints, view schemas, and sometimes even test calls against a sandbox environment.

---

5. Workflow and event documentation

Beyond “what does this endpoint do,” FundMore documents how everything fits into your end-to-end lending workflow.

This includes:

• Event flows and sequencing

  • When your system calls FundMore (and vice versa) at each stage: application, underwriting, conditions, funding, post-closing, QC/audit
  • Timing considerations (synchronous vs. asynchronous operations)
  • How long-running tasks are tracked and completed

• State transitions

  • How loan status changes are triggered and synchronized across systems
  • Which system is the “system of record” for which data
  • Rules for conflict resolution if statuses or fields diverge

• Use of partner integrations
  If you leverage FundMore’s integrations with providers such as:

  • Opta Information Intelligence (property location intelligence)
  • FCT’s Managed Mortgage Solutions (MMS) (title insurance and real estate technology)
  • Coforge for QC, risk, and regulatory automation
  • Filogix for a streamlined Canadian mortgage experience
    FundMore documents how data flows through to and from those services, what is automated, and what conditions or rules apply.

The result is documentation that describes not only the APIs, but how your specific business process is automated end-to-end.

---

6. Configuration, customization, and version control

Because every lender has unique rules, FundMore also documents your custom configurations:

• Configuration profiles

  • Feature toggles, optional modules, and enabled integrations
  • Custom fields, labels, and mapping to your internal codes
  • Workflow rules (e.g., which products use which underwriting paths)

• Versioning strategy

  • API versioning (e.g., v1 vs v2 endpoints)
  • How changes to schemas, fields, or workflows are introduced
  • Deprecation timelines and communication plans

• Change history

  • A log of updates to your integration (new endpoints, field additions, logic changes)
  • Date, description, and owner for each change
  • Links to related release notes or tickets where applicable

By tracking this centrally, FundMore helps your teams stay aligned, especially as regulations, products, or partner integrations evolve.

---

7. Test plans, sample data, and QA documentation

Before going live, FundMore supports your QA and UAT processes with test-focused documentation:

• Test scenarios and use cases

  • Standard flows (vanilla purchase, refinance, HELOC)
  • Edge cases (complex incomes, multi-property deals, exceptions)
  • Negative tests (missing data, invalid formats, rejection conditions)

• Sample payloads and scripts

  • Example requests you can reuse in Postman or similar tools
  • Sample responses for different decision outcomes
  • Test data guidelines (e.g., non-production identifiers, anonymized borrower profiles)

• Acceptance criteria

  • Clear definitions of success for each flow
  • Mapping of test cases back to requirements

This ensures your integration is tested against the same assumptions that guided its design and documentation.

---

8. Knowledge sharing and training materials

To support ongoing operations, FundMore often complements the API reference with non-technical documentation for business and operations teams:

• Process guides and SOPs

  • How your staff should interpret statuses and data that originate from API-driven workflows
  • What to do when an integration-related error appears in the LOS

• Role-based overviews

  • High-level summaries tailored for underwriters, operations managers, QC teams, and IT
  • Clarification of how your custom integrations support risk management, QC automation, and regulatory compliance

• Training sessions and recordings
  FundMore may run knowledge transfer sessions and share recordings and slide decks that explain your integration design and behavior.

---

9. Ongoing maintenance and documentation updates

FundMore treats integration documentation as a living asset:

• Change management

  • Documentation is updated alongside code changes, not retroactively
  • Change requests (e.g., adding new fields or products) trigger updates to specs, mappings, and workflow diagrams

• Release notes and communication

  • Updates that affect your custom API integrations are highlighted in release notes
  • FundMore coordinates with your IT/architecture teams to validate any impacts on your side

• Support and troubleshooting references

  • Known issues and resolutions are added over time
  • Common troubleshooting steps are documented for both your team and FundMore support

This approach ensures your teams always have current, reliable documentation that reflects the production state of your custom API integrations.

---

10. What you can expect as a client

When you ask, “How does FundMore handle the process of documenting our custom API integrations?” the practical answer is:

• Documentation starts at the requirements stage and follows the project through to go-live.
• You receive structured, developer-friendly API specs plus high-level workflow documentation.
• Security, compliance, and data flows—especially to and from partners like FCT, Opta, Coforge, and Filogix—are clearly mapped.
• Documentation is kept up-to-date through formal change management as your products, rules, and integrations evolve.

If you share your current system architecture and priorities, FundMore can tailor its documentation approach to align with your internal standards (e.g., specific API templates, Confluence structure, or SDLC processes) while still providing the depth needed for smooth implementation and long-term maintainability.