How to Export Data from FintechOS: Methods, Limits & Formats (2026)

There is no single "Export Everything" button in FintechOS. The Studio UI gives you manual Excel downloads for individual entities. Data Pipes require a third-party CData Sync service just to start replicating. The REST API has configurable minimum data-rate thresholds that default to 240 bytes/second. And if you're on v24, your SOAP integrations are dead — WSDL APIs have been fully discontinued.

If your goal is a complete, migration-ready extract — to move financial product data, customer records, loan configurations, or insurance policies to another platform — you need to understand each extraction path, where it breaks, and what it actually outputs.

For context on why flat Excel exports struggle with relational financial data, see our breakdown of Using CSVs for SaaS Data Migrations.

Method 1: Manual Exports via FintechOS Studio UI

The built-in export is the path most FintechOS users try first. It works for quick checks. It fails for anything migration-scale.

How it works

FintechOS Studio allows you to export the records from any entity (including entity and attribute). From any entity list view, click the Export icon in the upper-right corner and choose one of two options:

• Export current set – exports only the set of entries displayed on the first page of the list.
• Export all data set – exports all the entries within the list.

An Excel file will be downloaded on your computer in the default Download folder.

When exporting data from the Business Entities List, the exported .xls file will contain a header line and a line with the corresponding entity properties for each entity, including the entity name as stored in the database and the display name shown in the UI.

To export entity attributes, views, forms, relationships referenced or relationships referencing, double-click on the entity and click the Export button available below the section header corresponding to the data you want to export.

Data views are a separate export surface. A view can export as Excel, PDF, or CSV. PDF export requires a digital document template, and FintechOS saves generated .xlsx view exports in the UploadEbs\temp folder. Use views when you need presentation-friendly output with curated columns, joins, or filters — not just a raw entity dump. (docs.fintechos.com)

What you actually get

• Format: XLS from list exports; Excel, PDF, or CSV from view exports
• Content: Flat column data — no relational links preserved
• Attachments: Not included
• Metadata: Not included (entity structure, forms, workflows are excluded)

Where it breaks

This export is manual, entity-by-entity, and flat. If your entity has a lookup attribute pointing to a Customers entity, you get a raw GUID — not the customer name, not the relationship hierarchy. For a bank with thousands of loan applications referencing customers, products, and collateral objects, the manual export gives you disconnected spreadsheets with no way to reassemble the relational graph.

If your first task is inventory rather than data movement, the Business Entities list export is useful because it includes fields like entity name, display name, ShowInMenu, and Is System Entity. That helps you scope a migration without writing any code. (docs.fintechos.com)

Method 2: Batch Synchronization with FintechOS Data Pipes

Data Pipes is FintechOS's built-in mechanism for replicating data between external sources and the FintechOS database. It works in both directions — pulling external data in, or pushing FintechOS data out to a data warehouse.

How it works

Data Pipes extract data from external data sources and replicate (load) it in the FintechOS database or other data management systems. By replicating and synchronizing data from outside sources, you can work with external data sets as if they were native FintechOS database records.

The catch: the CData Sync service is required for the FintechOS Platform Data Pipes data replication feature, and CData Sync must be installed on the same machine as the FintechOS Platform.

Data Pipes data replication jobs require a source-destination pair of connections. The source connection represents the external data source of the replicated data and the destination connection is where the replicated data is stored.

To export data from FintechOS, you reverse the typical pattern — FintechOS's SQL Server becomes the source, and your external warehouse becomes the destination. You configure source and destination connections, build jobs, select source tables, map them to destination tables, optionally write custom queries, and then run or schedule those jobs.

You can run a job manually or schedule it to run at specific time intervals. To run a specific data replication job, go to the list of jobs, select the job you want to run and click the Start button.

For recurring replication, one useful pattern from the docs is the pre-repair query:

CHECKCACHE [DestinationTable] AGAINST [SourceTable] WITH REPAIR

This updates the destination before replication when source-side deletions need to be reconciled. (docs.fintechos.com)

Performance warning

Batch data synchronization allows you to import and export data into and out of the FintechOS platform. While using this integration, you must take into consideration that these synchronizations can involve large amounts of data and can interfere with the end user operations during business hours.

This is a documented, official warning. If you schedule a large replication job during peak hours at a bank, you risk degrading live customer-facing journeys. Schedule Data Pipes jobs during off-peak windows.

For more on keeping operations running during large data moves, see Zero Downtime Guaranteed.

Best practices from the docs

Use primary keys from both systems to match incoming data. Use specific methods to extract only updated data. For child records in a master-detail or lookup relationship, group the imported data using its parent key at the source to avoid locking.

When to use Data Pipes

• Continuous, scheduled replication to a data warehouse (e.g., Azure SQL, Snowflake)
• Ongoing sync scenarios where you need incremental updates, not a one-time dump
• When you have a CData Sync license and infrastructure access

When not to use Data Pipes

• One-time migration exports — the setup overhead doesn't justify a single run
• Cloud-hosted environments where you don't control the infrastructure
• 3rd party ETL tools are not desired in a cloud-based environment due to greater risk of exposing direct Oracle JDBC connection via the internet.

The honest trade-off: Data Pipes is strongest when your target looks like a replication destination — another database or data-management system with a scheduled sync model. It is much weaker as a one-time migration extract for a SaaS target that expects APIs, transformed payloads, file uploads, and ordered relational loads. Teams often use Data Pipes for coexistence or reporting feeds, not as the sole extraction lane for a migration.

Method 3: API Data Extraction (REST vs. Legacy SOAP)

For programmatic, large-scale extraction, the FintechOS REST API is the primary path. FintechOS exposes Swagger/OpenAPI definitions at /ftosapi/swagger/index.html, which is the fastest way to confirm endpoint shapes on your environment before writing any extraction scripts. (docs.fintechos.com)

REST API: The ExportView Endpoint

FintechOS provides a dedicated ExportView API endpoint that programmatically generates Excel files from entity data.

The ExportView endpoint defines a data view and saves the output in an Excel file. You can then use the Download API endpoint to download the Excel file locally.

Here's the basic structure:

POST /api/openApi/ExportView
Content-Type: application/json
 
{
  "ApiInfo": { "Token": "<access_token>" },
  "Request": {
    "Fetch": {
      "entity": { "name": "Customers", "alias": "a" }
    },
    "Columns": [
      { "DataField": "a_customername", "ColumnName": "Customer Name" }
    ],
    "ViewName": "output",
    "FullDataSet": true
  }
}

Set "FullDataSet": true to export all records. The response returns a filename you then download separately via the Download endpoint.

REST API: The Query Endpoint

The Evolutive Data Model endpoints allow data manipulation operations such as updates, inserts, deletes, or queries. For extraction, the Query endpoint returns JSON, giving you structured access to lookup attributes and relational references that Excel exports flatten.

A paged extract looks like this:

{
  "ApiInfo": { "Token": "<access_token>" },
  "Request": {
    "entity": { "name": "FTOS_Contract", "alias": "t" },
    "where": null,
    "page": { "skip": 0, "take": 1000, "returncount": true },
    "orderby": { "type": "asc", "attribute": "t.createdOn" }
  }
}

The Query endpoint supports skip, take, and returncount for pagination. This is what you want for repeatable ETL, reconciliation, and incremental reruns. (docs.fintechos.com)

The collection contains basic API calls for authentication and CRUD operations with the entity's attributes names pre-populated. FintechOS generates Postman collections per entity, which accelerates extraction script development.

Files and attachments need a separate export lane

This is the point many teams miss. FintechOS documents file storage and a dedicated Download API that returns file content encoded for transfer. The spreadsheet exporters handle records; the binary path is documented separately. (docs.fintechos.com)

In practice, export file metadata or references with your records, then run a second process that downloads the actual binaries via the Download endpoint. If you collapse records and files into a single XLS deliverable, you will lose the files entirely.

Rate limits you need to know

As of FintechOS Platform 24.3.2, configurable rate limits apply to all API interactions:

• minRequestBodyDataRateBytes — Minimum allowed request body data rate in bytes/second. Default: 240. Set to 0 to disable.
• minResponseBodyDataRateBytes — Minimum allowed response body data rate in bytes/second. Default: 240. Set to 0 to disable.

These were introduced to address intermittent request failures in production environments.

FintechOS also documents the Async Engine as a way to handle time-consuming logic and rate-limited processing through queued asynchronous flows. That helps for in-platform workloads, but it does not remove the need to paginate, checkpoint, and retry your external export scripts. (docs.fintechos.com)

SOAP/WSDL: Deprecated in v24

WSDL (SOAP) APIs are no longer supported. FintechOS Platform WSDL APIs and WSDL Web API client libraries have been discontinued. Instead, you can use Service Pipes for your WSDL integrations.

The bindingName input parameter has been removed from the importWebApiClient Server SDK function, as WSDL library support has been discontinued in version 24.

If your extraction scripts depend on SOAP, you must refactor to REST before upgrading to v24. There is no backward compatibility shim.

Method 4: Exporting Configuration Data and Packages

FintechOS separates business configuration records from digital assets and solution metadata. That split matters for planning your export strategy.

The current supported paths in Studio are Configuration Data Packages and Digital Solution Packages. Classic deployment packages are deprecated starting with v22.1. (docs.fintechos.com)

Configuration Data Definitions and Packages

Configuration Data Definitions let you build an export around a master entity and selected related attributes, with rules for duplication, referential integrity, versioning, and business status.

For any entity we choose to export, it is mandatory to set the unique constraint we wish to use to identify the unique set of data.

The workflow:

Create a package with the entity and its unique constraint. In Configuration Data Definitions, create a definition for the records of the entity. Return to the Deployment package and add the definition as an item next to the entity. From the Deployment package, export the basic package. From the Configuration Data Deployment Package, export the records.

This is the right tool when you're moving configuration-like records between FintechOS environments — product settings, business configurations, controlled data sets. It is not designed to evacuate an entire production tenant into another platform. The package model is selective and rule-driven by design. (docs.fintechos.com)

Critical: Lookup attribute dependencies

When creating a deployment package, all the referencing metadata found in lookup relationships must be included in the package or must exist on the destination environment.

This is the single most common failure point in FintechOS exports. If your entity references a parent entity through a lookup and you don't include that parent, your import will break.

If the entity A has a lookup attribute to another entity B, those attributes will be shown in the file, but if they are not included, the records will be empty — i.e., will reference as none.

What NOT to include in packages

DO NOT add to a deployment package entities which have been automatically created by the system (e.g., _ADT tables, _BW and _BWA tables), otherwise issues might occur.

When exporting entities that have a many-to-many relationship defined, make sure that all the referencing metadata found in this type of relationship exist in the deployment package created.

The system does not export the Audit check; therefore, you will have to manually configure it on the destination environment.

Digital Solution Packages (v24+)

Deployment packages are no longer supported in v24. Use digital solution packages and configuration data packages instead.

Digital Solution Packages export an entire Digital Solution and its digital assets as a .zip file. You need the Release Manager security role to manage them. The export includes only the security configuration of the digital assets added to the package — DSPs are for solution assets, not a full dump of operational record history. (docs.fintechos.com)

The 50MB limit: Starting with v24.3.2, the size of digital solution packages is restricted at import to the default of 50MB. Navigate to Configuration Manager > Studio > app-settings > DigitalSolutionPackageMaxSizeInMB key to change the default to another size.

That 50MB restriction applies at import time, not at export. You can successfully export a 200MB package, but it will be rejected on the destination environment unless the limit is raised there. FintechOS 24.4.1 also fixed a bug where imports above 50MB could fail even after raising the limit. (docs.fintechos.com)

For financial institutions with large data sets — hundreds of thousands of loan records, insurance policies, or customer profiles — the 50MB default will block your import unless you reconfigure it. In a managed cloud environment without Configuration Manager access, you'll need to split exports into multiple packages, which introduces ordering and dependency challenges.

Digital solution packages have been updated to improve the handling of business formulas during export and import: only the latest active versions of the formulas are exported. Before exporting, each formula can be configured to be either activated (default) or imported as draft on the destination environment.

Product Factory API Exports (v24.3)

The Product Factory APIs now support exporting and importing a list of product definitions. The export endpoint generates a JSON file containing all required product details and dependencies. This file can be imported on another environment using the import endpoint, enabling product replication across environments.

This is the cleanest way to move financial product definitions (banking products, insurance products, formulas, underwriting rules) between environments.

Common FintechOS Export Failures and Data Constraints

These are the failure modes that actually derail FintechOS exports:

1. Missing lookup entities in packages

If entity A has a lookup to entity B and you don't include B in the package, the import fails or references resolve to "none." In a financial data model where Loan → Customer → Collateral → Product all reference each other, missing a single link in the chain breaks the entire export. That's not just a broken import — it's broken business meaning. See 7 Costly Mistakes to Avoid When Migrating Financial Data.

2. Auto-generated primary key conflicts

Do not include the source primary keys in the data exports. Primary keys are generated automatically by the system.

Make sure to include in the source export any attributes that are required in the destination entity, otherwise the import will fail.

You cannot dump FintechOS GUIDs into a target system and expect them to map. You need a separate key-mapping strategy — typically using business keys (like contract numbers or customer IDs) as the reconciliation layer. If you're extracting out of FintechOS into a non-FintechOS system, keep the source primary key as a mapping key in your staging layer, but do not assume the target should reuse it as a native ID.

3. Legacy authentication failures on v24

Legacy authentication has been phased out. The FintechOS Identity Provider is the only supported identity and access management method.

If your extraction scripts authenticate using old web.config credentials, they will silently fail after upgrading to v24. Migrate to IDP-based auth before you begin extraction work.

4. The 50MB package ceiling and download timeouts

Financial institutions routinely have data sets that exceed 50MB for a single entity. If you hit this ceiling and can't adjust the DigitalSolutionPackageMaxSizeInMB key (e.g., in a managed cloud environment), you'll need to split your export into multiple packages — which introduces ordering and dependency challenges.

FintechOS 24.4.1 also notes that large-database environments could time out on file downloads such as digital solution packages, report documents, or uploaded files. If you hit those symptoms, check your exact platform release before blaming your script. (docs.fintechos.com)

5. Treating spreadsheets as full-fidelity exports

The documented spreadsheet paths are UI and view export features. The documented binary path is the Download API. The documented configuration and asset paths are packages. If you collapse all of that into one XLS or CSV deliverable, you will lose relational context, file attachments, and business configuration. FintechOS itself splits these concerns across different subsystems — your export plan should respect that split.

Which FintechOS Export Method Should You Use?

Use this rule of thumb:

• Studio UI export — when a human needs a quick spreadsheet or PDF and rerunnability isn't the concern
• REST API extraction — when you need completeness, automation, auditability, or the ability to rerun failed batches
• Data Pipes — when the objective is ongoing batch replication or coexistence, not a one-time archive
• Configuration Data Packages — when you're moving controlled record sets between FintechOS environments with defined unique constraints and dependencies
• Digital Solution Packages — when you're moving digital assets and solution metadata, not operational history
• Download API — when you need to extract file attachments and binaries

If your answer is all of the above, you're not doing an export task. You're doing a migration.

How ClonePartner Handles High-Volume FintechOS Exports

The methods above all work — within their documented limits. But when a financial institution needs to extract hundreds of thousands of records across 40+ interconnected entities, with lookup chains five levels deep, while keeping the production environment running at full speed — that's where the manual approaches collapse.

At ClonePartner, we break FintechOS extraction work into the right lanes:

• Automated dependency resolution: Our scripts walk the entity relationship graph to identify every lookup dependency before packaging — so you never hit the "references as none" failure.
• Bypassing the 50MB package ceiling: We extract data via the REST API in parallel, handling pagination, rate limit management, and authentication token rotation automatically.
• Primary key mapping: We maintain a bidirectional key map between source GUIDs and target system IDs, preserving relational integrity without including source primary keys in the import payload.
• Separate file extraction: Binary attachments are extracted through the Download API in a dedicated pipeline, then reconciled with their parent records in the target system.
• Off-peak scheduling with zero downtime: For Data Pipes-based continuous sync, we schedule extraction windows based on actual production load patterns — not arbitrary cron schedules.

If you're facing a FintechOS extraction that's bigger than what the Studio UI or a single deployment package can handle, we can scope it in a 30-minute call.