Secure File Delivery
Secure File Delivery (SFD) is Synctera’s batch delivery service that makes key operational and analytical datasets available to banks and fintech partners over SFTP using PGP-encrypted files. Many banking and payments workflows require regularly updated extracts of accounts, parties, transactions, and balances. These extracts are used for periodic operational and regulatory processes, and also ad hoc analyses. These often contain non-public personal information (NPPI) or personally identifiable information (PII), so they cannot be shared over email or consumer file-sharing tools. Synctera’s SFD architecture provides a secure, reliable way to deliver these datasets:- Files are PGP-encrypted with the partner’s public PGP key.
- Files are delivered to a dedicated folder on Synctera’s SFTP server for each bank or fintech.
- Access requires both valid SFTP credentials (private SSH key) and possession of the corresponding private PGP key.
- Synctera employees cannot decrypt the files because we do not hold customer private keys.
-
Security
- All SFD files are PGP-encrypted before being placed on SFTP.
- Only the holder of the private key can decrypt the contents.
- SFTP access is restricted to authorized users for that bank or fintech.
-
Privacy
- Personally identifiable information (PII) is tokenized and stored in secure vaults at rest.
- Synctera de-tokenizes in memory only during file generation, then re-tokenizes or removes sensitive values from internal systems as appropriate.
-
Reliability at scale
- The pipeline is built to handle growing volumes of accounts and transactions as programs scale.
- For commonly-requested datasets, Synctera supports incremental (delta) delivery, which significantly reduces file sizes and processing load compared to full history dumps.
Delivery patterns: full history vs incremental (delta)
Historically, SFD delivered full history files every night: each file contained the complete dataset (for example, all accounts or all transactions for a tenant to date). As volumes have grown, this pattern has become expensive and brittle for both Synctera and partners. To address this, SFD now supports incremental (“delta”) delivery for many core datasets. Bank and fintech partners set up after Nov 2025 receive delta files by default.Full history files
A full history file contains all rows in a given dataset for the configured tenant(s), regardless of when each row was created or last updated. Typical use cases:- Initial warehouse loads
- Large-scale re-reconciliation or backfills
- Off-cycle data migrations
Incremental (delta) files
A delta file contains only rows that are new or have changed since the last successful SFD delivery for that dataset and tenant. Key properties:- Much smaller file sizes than full history files
- Faster to ingest and process
- Better aligned with modern ETL/ELT “upsert/merge” patterns
- Initial full history file to establish a baseline in the partner’s environment.
- Nightly delta files that partners apply as upserts/merges to keep their warehouse in sync.
Commonly requested files and delivery patterns
The table below summarizes the standard SFD datasets and their typical delivery patterns. If you need a dataset not listed here, or want to confirm whether a specific file can be delivered as deltas for your tenant, please contact your Synctera representative.| Dataset | Description | Delta availability |
|---|---|---|
| Accounts | Full breakout of accounts and their relationships with customers (one row per account-customer relationship). Covers deposit and loan accounts, account status, and relevant dates and metadata. | ✅ |
| Parties | Full listing of all end consumers that have completed FinTech initial signup process. Includes both users that have completed onboarding and become bank customers as well as those that either failed or did not complete onboarding and account opening. One row per end consumer party (business or personal). | ✅ |
| Bank Customers | Listing of end consumers that have completed FinTech onboarding and become a full customer of the bank. This is a subset of the Parties view. One row per end consumer party (business or personal). | ✅ |
| Customer Addresses | Listing of addresses associated with an end consumer party. Provides a lookup to the party itself, and can provide multiple addresses (shipping, legal, etc.) and a history of previously registered addresses. One row per customer - address linkage and relevant history. | ✅ |
| Transactions | Register of transactions on accounts associated with the tenant. Provides one row per transaction, with “from” and “to” account data, and relevant dates / metadata on the transactions. | ✅ |
| Account-centric transactions | Register of transactions on accounts associated with the tenant. Provides two rows per transaction, one row for each of the “from” (debit transaction line) and “to” (credit transaction line) accounts, and includes relevant dates / metadata on the transaction. | Not yet available, on the roadmap |
| Cards | Listing of customer payment cards associated with accounts on the tenant. Provides one row per card created. Includes metadata on card types, shipping data, and dates. | ✅ |
| End-of-day account balances | Daily register of end of day balances for accounts associated with a tenant. Includes customer accounts, internal (FinTech) accounts on the Synctera ledger, and relevant accounts at the Sponsor Bank (where provided by the sponsor bank). One row per account per day. | ✅ |
| Case resolution overview | Listing of Synctera platform cases and their current status / relevant metadata. One row per case created on the Synctera case platform. | Not yet available, on the roadmap |