Client Data-Migration Spec (Bulk Customer Import)

This is the practical, "what do you actually send us" companion to docs/investor/technical-architecture.md's "Client data migration & onboarding" section and docs/staff-operations-guide.md's migration procedure. It's written for a client bank/credit union's own IT/ops team preparing to move their existing customers onto Coreledgerpay, and for Coreledgerpay staff/sales having that first "how do we get our data over" conversation.

It is deliberately core-system-agnostic: Coreledgerpay does not have a live, certified connector into Fiserv, FIS, Jack Henry, or any other core banking system today (see the honest gap called out in Technical Architecture and Competitive Analysis) - building one speculatively, before a specific client has confirmed a specific core (and often a specific product within that vendor's lineup - e.g. Fiserv DNA vs. Premier are very different systems), would be guessing at a very expensive integration. What follows instead is a plain file format any core's own export/reporting tools can produce, plus general guidance on where to look for each field regardless of which core a client runs.

What's actually built today (read this first)

• Bulk import of customers, one account each, at their current balance. Not a bespoke connector, not a live sync - a file upload, previewed and validated in the staff console before anything is committed, then run through the same identity + account creation used for a single migrated customer (see the staff-operations-guide procedure).
• Bulk historical-transaction import is supported too, via a second, linked upload. Alongside the current balance, an optional second CSV of historical transactions - amount, currency, description, type, and the date they actually occurred - can be uploaded together with the customers file, joined by each customer's own sourceSystemReference. Each transaction is recorded on the new account exactly as a historical record (its own real date, not the migration date), without moving any real money (the account's current balance already reflects everything these records describe). A client that only needs the current balance carried over (the common case for a small/greenfield client) can simply skip this second file. See "The transaction-history file format" below.
• Not yet built: automatic core-system extraction. Nothing pulls data directly out of Fiserv/FIS/Jack Henry/etc. - the client's own team (or their core vendor, on request) produces the export file(s) described below.
• Batch size: up to 200 customers per uploaded file. A larger existing customer base is migrated across multiple files/uploads rather than one enormous batch - this keeps each run fast, reviewable, and easy to re-run if a handful of rows need fixing, rather than an all-or-nothing multi-thousand-row commit. There is no separate cap on the transaction file's row count - a customer with a long history simply has more rows in that file, all attached the same way.

The file format

One row per customer, as a CSV file (UTF-8, comma-separated, a header row matching the column names below exactly). The admin console's Migrations tab has a "Download CSV template" button that produces this exact format with one example row filled in - use it as the starting point rather than building the file from scratch.

The transaction-history file format (optional, second upload)

A separate CSV, uploaded after the customers file above (the console matches its rows to that file's customers by sourceSystemReference, so it needs to already be loaded). One row per historical transaction - a customer with 200 past transactions has 200 rows here, all sharing that customer's sourceSystemReference. This is deliberately a second, linked file rather than extra columns on the customer file itself, since a customer can have anywhere from zero to hundreds of historical transactions - a fixed number of "transaction 1, transaction 2, ..." columns wouldn't scale, and most rows in the customer file would need almost all of them left blank. The Migrations tab has its own "Download transactions CSV template" button for this file.

Why identity verification is skipped for migrated customers

A migrated customer's identity record is created already verified in Coreledgerpay, not re-run through the normal KYC review queue - your institution already verified this customer's identity when they first opened their account with you, and re-verifying identity documents that already exist in your own records would be redundant friction for a customer who isn't actually new. migrationNote exists specifically so that shortcut is auditable, not silent.

Where to find these fields in your own core, without an API integration

None of this requires your core vendor's cooperation or an API certification - every core banking system supports operational reporting/extract tools that a client's own admin already has access to. General guidance, since Coreledgerpay has no live connector to verify exact menu paths against for any of these:

• Fiserv (DNA, Premier, and others): customer/account extracts are typically produced through the core's own reporting module or a scheduled data-export job your operations team already runs for other purposes (statements, regulatory reporting, etc.) - ask your Fiserv relationship manager or in-house core administrator for a "customer and account balance extract," not an API integration.
• FIS (Horizon, IBS, and others): similarly available via FIS's reporting tools or batch extract jobs; your core administrator can typically produce a flat-file customer/balance export without involving FIS directly.
• Jack Henry (SilverLake, CIF 20/20, Symitar, and others): Jack Henry's platforms are generally the most self-service of the three for this kind of extract; your core administrator or a Jack Henry-certified in-house report can usually produce this directly.
• Anything else (a smaller/homegrown system, or a spreadsheet-based system for a very small credit union): if your existing customer records already live in a spreadsheet or simple database, you may be able to skip an extract step entirely and map straight into the CSV format above.

In every case, the deliverable Coreledgerpay needs is the CSV file(s) described above - not raw access to your core, not an API integration, and not a specific file format unique to your vendor.

End-to-end process

1. Scope the batch. Client and Coreledgerpay staff agree on which customers are migrating in this batch (see Roadmap to Launch's guidance on phased/parallel-run cutovers for anything beyond a very small client).
2. Client produces the customer CSV (and, if bringing over historical transactions, the linked transaction-history CSV too) using the formats above, from whatever export/reporting tool their core supports.
3. Client generates (or agrees on a process for generating) a claimSecret per customer and a plan for communicating it to each customer separately from any data transfer to Coreledgerpay.
4. File(s) transferred to Coreledgerpay staff securely - not over unencrypted email; use whatever secure file-transfer channel is already part of your institution's vendor-data-sharing process.
5. Coreledgerpay staff upload the customer file, then (optionally) the transaction-history file, in the admin console's Migrations tab, review the preview (which flags any customer row missing a required field, and any transaction row that doesn't match a customer or fails to parse, before anything is committed), and run the migration.
6. Staff reconcile each migrated account's balance against the source system in the "Migrated accounts" queue, marking each reconciled or flagged.
7. Customers activate their own accounts at /claim (or the mobile app's "Migrating from another bank? Activate your account" screen) using their email and claim secret, choosing their own password.

See docs/staff-operations-guide.md for the staff-facing steps in detail, and docs/user-guide.md for what a migrated customer sees.

This page is generated from the same source that powers in-app help, so it always matches the current release.