Financial Services
›
Financial Services & Banking
›
Core Banking Systems
Core Banking Modernization
Regulated environments where trust, compliance, and operational resilience are non-negotiable.
Example organizations in this space:
Temenos
Finastra
Jack Henry
FIS
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Outcome Discovery
Align on desired business outcomes, current core constraints, migration risk tolerance, stakeholders, and measurable success signals.
Discovery Questions
Why now: what pushed this to the top of your list
- Tell me about what is motivating your team to evaluate a new core platform today
- How long have senior leaders been discussing a core replacement, and what changed to increase urgency
- Describe the last time your legacy core caused a customer-facing outage, a report failure, or required a multi-day reconciliation, and what that cost you operationally
- Which business goals does your leadership expect a migration to deliver in the first 12 months
- Name the executive sponsor most accountable for the modernization outcome
Where the current system breaks trust
- If your current core caused a single regulatory filing failure or customer outage tomorrow, what would break and who in your organization would notice first
- How often do reconciliation mismatches, delayed transactions, or manual journal fixes occur that require escalation
- Give an example of a product, payment flow, or integration you cannot launch today because of the core, and name the specific technical or data blocker
- When those failures occur, estimate the typical downstream cost in staff hours, customer callbacks, or regulatory effort
- Select the effect that strains your compliance, operations, or customer experience the most
Constraints that will pause or stop the project
- Name the single integration, approval, or dependency that, if missing, would force you to pause or halt a migration
- List the external systems that must be integrated during phase one, and for each note whether an API or extract is available
- Identify the owners of access and credentials for each system, and how quickly they can grant it
- Estimate the number of dedicated staff your organization can assign to the migration program and whether any are already billable to other projects
- Is there a regulator, internal compliance board, or legal review that must preapprove cutover steps, and what is the typical lead time
- What data quality issues exist today, for example duplicate accounts, missing identifiers, or historical balance mismatches, and which of those would prevent automated conversion
The other paths you are weighing
- List the alternatives you are evaluating that could keep you from moving forward with an external migration partner
- For each alternative you named, what specific evidence or milestone would need to exist for you to choose it over an external migration partner
- Has anyone on your team proposed solving this problem internally without an outside partner, and if so, who proposed it
- Tell me which incumbent vendors or your existing core you might stay on and explain the main reason
- Specify the timeline, cost, or risk threshold that would tip the balance back to the incumbent or a do-nothing approach
If this worked perfectly, how would your next year change
- If you could guarantee one measurable business outcome from migration in the first 12 months, what would it be
- Envision three KPIs you would use to judge success at month 3, month 6, and month 12
- Assign an owner for each KPI and state the reporting cadence you expect
- Rate how acceptable a temporary increase in operational load during migration would be, on a scale of 1 to 5 where 1 is unacceptable and 5 is fully acceptable
- Specify the revenue lift or cost reduction target that would make the board or executive committee agree to continue to the next migration phase
Who must sign and who will run it
- Which stakeholder has the power to veto the program, and what evidence would they need to change their mind
- Provide the names, roles, and decision rights of the steering committee or governance group you expect for this program
- Describe the program manager and deployment team profile you think will be required, and whether those people exist internally
- Estimate the percentage of FTE capacity operations and IT can dedicate during peak migration weeks
- Who will own contracting and procurement, and what is the typical internal approval timeline
- Explain your fallback plan for continuity if a key resource leaves mid-project
Acceptance criteria, rollback, and stop conditions
- What single acceptance failure during parallel run would make you refuse cutover
- Define the minimum data parity thresholds you require across balances, transactions, and fees for go-live, with concrete examples
- Select the reconciliation cadence and automated checks you require during parallel run
- Explain the rollback criteria and the expected time window in which rollback capability must function
- Who signs the final go-live acceptance and under which conditions would they delay sign-off
Decision drivers and concrete next steps
- Assuming a proof of concept validates the migration numbers you need, what would still remain that prevents signing within 30 days
- Provide your target commercial window for signing and the approval milestones that must be reached
- Identify the contractual terms or procurement hurdles that typically slow you down
- State the budget allocated today and your expected migration cost range
- Point to the decision that would accelerate signing from pilot to contract within 30 days
-
Solution Experience
Translate outcomes into concrete scenarios showing the phased migration approach, data conversion methodology, integration surface area, and regulatory controls in the buyer's context.
Solution Experience
- Solution Experience: Phased Migration Scenarios
- Confirm the current state and its cost
- You confirm the proposed phased conversion sequence eliminates the single big-bang risk and matches your migration risk tolerance.
- Deliver a tailored phased migration scenario document for the prioritized product lines within 7 business days.
- You confirm the data conversion and reconciliation approach will achieve transaction parity for deposits and loans relevant to your operations.
- Map migration scenarios for priority product lines
- Provide two migration reference summaries at institutions in the same asset range, highlighting outcomes and lessons learned.
- Provide the list of priority product lines, current integration endpoints, and a sample anonymized dataset for conversion proof-of-concept.
- You confirm the integration approach preserves live connections to payments, lending, and digital channels during each migration phase.
- Show the data conversion and reconciliation approach using your context
- Review integration surface and regulatory controls
- You agree on the remaining evidence and acceptance criteria required by your procurement and regulator-facing stakeholders.
- Identify the regulatory contacts and the preferred acceptance criteria for each prioritized product line.
- Validate the future state
- Agree next evidentiary steps for your buying committee
- Solution Experience: Phased Migration Scenarios
- Solution Experience Deck
- Solution Brief
- meeting
- slides
- document
-
Solution Scope
Define scope boundaries, product-line migration sequencing, responsibilities, acceptance criteria, and out-of-scope items for the phased conversion.
Scope Configuration
- Migrate Deposit Product Records
- Migrate Loan Account Records
- Migrate Historical Transaction History
- Convert General Ledger Balances
- Configure Product Catalog and Pricing
- Enable Real-Time Transaction Processing
- Deliver Open Banking API Endpoints
- Integrate Payments Network (ACH/Wire/Card)
- Integrate Digital Banking Provider
- Integrate Third-Party Lending Systems
- Run Parallel Processing and Dual-Write
- Automated Data Reconciliation and Exception Handling
- Execute Phased Product Cutover and Go-Live
Scope Questions
Migrate Deposit Product Records
- How many deposit product SKUs (checking, savings, money market, CDs) need full record migration?
- Which core data extracts will we receive for deposit products (flat files, DB dump, scheduled API feed)?
- What specific deposit attributes must be preserved (e.g., tiered interest bands, minimum balance flags, skip-a-month features)?
- Who in your team owns mapping of deposit product codes to the target product catalog and will approve the mapping deliverable?
- Do you have legacy check-image or deposit slip linkage that must be associated to migrated deposit records?
- What is the maximum allowable cutover exposure for deposit posting downtime in minutes (window we must meet for SLA planning)?
Migrate Loan Account Records
- How many active loan accounts and loan types (mortgage, commercial, consumer installment, HELOC) require record migration?
- What loan artifacts must be migrated with accounts (amortization schedules, escrow balances, payment histories, origination docs)?
- Which interest rate structures are present that require custom conversion logic (step-rate, index-linked, rate floors/ceilings)?
- Who will validate converted loan payoff and outstanding principal amounts during cutover verification?
- Do you require inclusion of charged-off or closed loans in the migrated dataset for collections continuity?
- What downstream system links must be preserved for loans (loan servicing platform, investor reporting feed, loan-level MIS export)?
Migrate Historical Transaction History
- What lookback window of historical transactions do you require per account for transaction history (e.g., 1 year, 7 years for statements)?
- Which transaction types and artifacts must be preserved (cleared checks, POS card transactions, ACH trace numbers, check images)?
- What file formats do your archival systems currently provide for history (microfilm scans, TIFF/PDF images, flat CSV, normalized transaction ledger)?
- Who will approve the transaction retention policy to guide which historical transactions are loaded versus linked-at-archive?
- Do you have regulatory retention needs tied to accounts (e.g., 7 years for certain statements) that must be flagged in the migrated history?
- Describe any customer-facing history displays that must match legacy behavior (e.g., running balance calculation method, original posting timestamps).
Convert General Ledger Balances
- Which GL control accounts and mapping documents will you supply (deposit control numbers, loan principal control, suspense accounts)?
- What reporting cutover balance time must be achieved for GL (end-of-day parity, intra-day parity)?
- What tolerance threshold for balance variance do you accept during conversion (e.g., 0.01%, $100 absolute)?
- Who will sign off on GL mapping including chart of accounts alignment and opening balance adjustments?
- Do you require automated journal entry generation for conversion adjustments into the target general ledger?
- What regulatory reports depend on GL parity at cutover (call report, FR Y-9, or analogous national regulator) and must be validated post-migration?
Configure Product Catalog and Pricing
- How many product catalog entries (unique deposit rates, loan products, fee schedules) require configuration in the target system?
- Which pricing artifacts must be translated (tiered interest matrices, balance-based fees, promotional rate periods)?
- What rule engine behaviors must be reproduced (grace periods, fee assessment timing, interest calculation rules)?
- Who will approve the canonical product catalog and pricebook before configuration is locked?
- Do you require support for promotional campaigns (temporary rate overrides) and a rollback plan for expirations?
- Provide the expected frequency of price changes (monthly, quarterly, ad hoc) to plan configuration release cadence.
Enable Real-Time Transaction Processing
- Which transaction classes require real-time processing (ATM/POS authorization, online transfers, ACH same-day credits)?
- What peak transactions per second (TPS) must the platform support to match current peaks?
- Do you require latency SLAs for customer-facing flows (authorization <200ms, balance lookup <150ms)?
- Who will certify production readiness for real-time pipelines and approve load testing results?
- Which monitoring alerts should be configured for real-time failures (transaction drop, publish/subscribe lag, queue depth thresholds)?
- Are there regulator-driven reporting latencies (e.g., intraday reporting windows) that the real-time system must feed?
Deliver Open Banking API Endpoints
- Which API capabilities must be delivered (account information, payment initiation, transaction history, consent management)?
- What authentication pattern will you require for partners (OAuth 2.0 with client credentials, user consent OAuth flow)?
- Which regulatory standards or schemes must the APIs comply with (NACHA for payments, PSD2-style consent models, national open banking profile)?
- Who will provide API client onboarding details and approve scopes for production clients?
- Do you require API sandbox environments and test data with representative account numbers and synthetic transactions?
- Provide expected external consumer types for the APIs (fintech partners, digital banking provider, internal apps) to plan consent models.
Integrate Payments Network (ACH/Wire/Card)
- Which payment rails must be connected at go-live (NACHA ACH, Fedwire, card acquirer networks)?
- How are current payment flows delivered from the core (NACHA files over SFTP, real-time ISO 8583 gateways, host batch files)?
- Who owns settlement reconciliation and will approve test transactions for each rail?
- Do you require tokenization or card-on-file migration for recurring card payments during cutover?
- What fraud or risk screening integrations must remain in place (third-party AML/OFAC screens, in-house rules)?
- Are there settlement timing constraints we must preserve (same-day ACH windows, end-of-day card batch close)?
Integrate Digital Banking Provider
- Which integration pattern do you expect with your digital banking provider (API connector, nightly file sync, message queue)?
- What product features must the integration support at cutover (balance display, funds transfer, bill pay, mobile deposit)?
- Who will provide API credentials, callback URLs, and approve client scopes for the digital banking integration?
- Do you require single sign-on federation or customer identity synchronization during migration (OAuth, SAML)?
- Describe any customer UI expectations that must be maintained across cutover (statement history continuity, pending transaction behavior).
- Will you require parallel validation with the digital banking provider to confirm transaction parity for a pilot cohort?
Integrate Third-Party Lending Systems
- Which third-party lending systems must remain integrated (loan origination, investor servicing, collections platforms)?
- What integration method exists today for each lending system (REST API, batch files, MQ)?
- Who will own certification testing with each third-party lending vendor to validate interface behavior?
- Do investor reporting feeds require loan-level identifiers preserved exactly as in legacy exports?
- List any regulatory investor or trustee files that must be produced from the new platform post-migration.
- Are there contract or connectivity constraints with third-party vendors (certification windows, security questionnaires) that will affect schedule?
-
Mutual Commit
Finalize commercial and legal terms, confirm governance, sign off on dependencies and acceptance criteria, and document migration success metrics.
Agreement Modules
- Master Services Agreement (MSA)
- Statement of Work (SOW)
- Subscription & Order Form
- Service Level Agreement (SLA)
- Data Processing & Regulatory Compliance Addendum
- Migration Acceptance & Success Metrics
- Governance & Steering Committee Charter
- Change Order Agreement
- Source Code Escrow & Continuity Agreement
-
Deployment
Operationalize rollout with readiness checks, execution, and outcome validation.
-
Pre-Deployment Readiness
Capture concrete readiness facts the deployment depends on — environments, data owners, cutover windows, regulatory contacts, and rollback plans.
Pre-Deployment Questions
Environment and access
- Which target environments are included in this phase and what is the expected readiness date for each (e.g., production, integration, sandbox) — this lets the deployment team schedule environment validation and tests.
- Are the buyer's integration endpoints reachable from the platform's deployment network so connectivity and end-to-end tests can run?
- Has network/VPN/firewall access been approved and a change window secured that allows test and cutover traffic through buyer infrastructure?
Data and configuration
- Which product lines and datasets are in scope for this initial phase? (select all that apply — this populates conversion and reconciliation tasks)
- Is a field-mapping approach decided and a named owner assigned to approve mappings per dataset? (we need a single approver to unblock conversion)
- Who is the authoritative owner for source-of-truth customer and account data? (provide name and role — owner will sign conversion acceptance)
People and ownership
- Identify the named deployment owners (provide name and role) we will list on runbooks and escalations: project manager, technical lead, data conversion lead, operations lead.
- Are escalation paths and a 24/7 on-call contact defined for the cutover period?
Timing and constraints
- List preferred cutover window(s) and any firm blackout periods (include local timezones) — we use these to schedule rehearsals and the final cutover.
- Does the buyer require a formal rollback decision point and a defined rollback window post-cutover (so we can plan hold/reconciliation cadence)?
- Are regulatory reporting or supervisory approvals required before cutover, and is a regulatory contact assigned and available to confirm clearance?
-
Configuration Details
Lock exact configuration values the deployment team will use — data mapping rules, reconciliation settings, integration endpoints, and API credentials.
Configuration Details
Locking Production Endpoints
- Enter the production environment name (single token, lowercase). Default: 'prod'. This exact name will be used in deployment manifests.
- Enter the production API base URL (format: https://...). This exact URL will be configured as the platform connector endpoint.
- Select the production cloud region for service deployment. Default: 'us-east-1'.
Securing Auth & Secrets (identifiers only — no secrets)
- Select the authentication method the platform will use to authenticate to your systems (we will request the non-secret identifier only). Default: 'OAuth2 (client credentials)'.
- Enter the non-secret integration identifier tied to the chosen auth method (format: client_id, certificate name, or api_username). Do not paste secrets.
- Where will secrets (client_secret, private keys) be stored or exchanged? Select the buyer-managed or agreed method. Default: 'Buyer-managed secrets manager (provide name next)'.
Data Mapping & Reconciliation Rules
- Enter the canonical source system name for account master data to be mapped (single value, e.g., 'legacy-core-mainframe').
- Select the reconciliation approach the deployment should run during each cutover validation. Default: 'Automated parity checks with exception report'.
- Specify the numeric tolerance threshold for reconciliation mismatches that the build should auto-accept (format: integer count OR percent, e.g., '0' or '0.1%'). Default is '0' (no auto-accept).
Operational Controls & Acceptance Hooks
- Enter the exact path or filename pattern where the buyer will place the data conversion mapping file for ingestion (format examples: s3://bucket/path/mappings.csv or \\server\share\path\mappings.json).
- Provide the team or role that owns integration credentials and will approve secret handoff (format: team-name or role, e.g., 'IT-Security'). Default: 'IT-Security'.
- Provide the operational notification recipient(s) for deployment alerts (format: comma-separated emails or a distribution list). Default: '[email protected]'.
-
Deployment
Execute the phased migration with sequenced tasks, named owners, parallel processing controls, and automated reconciliation checkpoints.
-
Go-Live Acceptance
Formal acceptance checklist verifying data integrity, transaction parity, regulatory reporting, monitoring, and rollback capability before final cutover sign-off.
Checklist items
- Execute full cutover dry‑run (dress rehearsal)
- Produce parity reconciliation report for all migrated product lines
- Create immutable rollback point and successfully restore it in test
- Generate representative regulatory reports from the new system and obtain acceptance
- Validate monitoring, alerting, and dashboards for critical workflows
- Run and verify automated reconciliation jobs are scheduled and passing
- Execute end‑to‑end integration tests for all in‑scope endpoints
- Confirm audit logging, access controls, and retention settings are enabled and verifiable
- Obtain operational readiness acceptance from buyer operations lead
- Obtain signed Go‑Live Acceptance (final cutover sign‑off) from designated approver
-
-
Success
Maintain a post-deployment cadence to validate outcomes, run recurring success reviews, and track issues and enhancement requests.
Success Reviews
- Go-live Health Check (week 1-4)
- First Measurement Review (weeks 4-10)
- Acceptance Gate, Outcome Validation (around day 90)
- Quarterly Success Review
Issues & Enhancements
- Schedule the next quarterly review and any interim checkpoints required for critical remediation items.
- Create remediation tasks for each identified root cause with completion dates and verification steps.
- Schedule an interim checkpoint if any corrective action requires more than two weeks to complete.
- Restate acceptance criteria and targets
- Record a documented pass or fail decision for every acceptance criterion listed in Solution Scope, with evidence references.
- Confirm the incumbent system wind-down status and actions to prevent split operations or fallbacks.
- Agree remediation tasks and timelines for any failed criteria, with verification steps and a re-evaluation date if required.
- Publish the formal acceptance record with evidence links and the named signatory captured in the project file.
- If any criteria failed, open remediation tasks with verification steps and target close dates for follow-up tracking.
- If incumbent wind-down is incomplete, schedule and track the remaining decommission steps including contract and archive actions.
- Review metric trends vs targets
- Verify that monthly production incident minutes and automated reconciliation success rate are within acceptable bounds or have a concrete recovery plan.
- Prioritize persistent issues and enhancement requests and place them into a tracked backlog with due dates.
- Confirm any regulatory actions required in the next quarter and owners for those actions.
- Publish the quarterly metric dashboard with trend lines and the agreed backlog prioritization.
- Open delivery tasks for high-priority enhancements and attach acceptance criteria and verification steps.
- Re-confirm success criteria and owners
- Confirm that the new core is processing production work with no critical outages that block customer-facing flows.
- List all open incidents with clear owners and target resolution dates for immediate remediation.
- Confirm the timeline and data sources for the first quantitative measurement meeting.
- Publish the post-cutover validation checklist with status and owners for each item.
- Open incident tickets for any critical issues and record remediation target dates.
- Share the data extract definition and schedule that will be used for the first measurement review.
- Present first measurement data
- Determine whether data migration completeness percentage and reconciliation mismatch rate meet or are on a clear path to meet Solution Scope targets.
- Agree a short list of corrective tasks with target dates that will be tracked to the acceptance gate.
- Confirm the data sources and owners responsible for the acceptance gate report package.
- Produce a metric reconciliation package that maps raw extracts to the presented metrics and distribute it ahead of the acceptance gate.
- Deployment and migration validation
- Open issues burn-down and status
- Present outcome data against each criterion
- Diagnose gaps and root causes
- Early adoption and usage signals
- Enhancement request triage
- Document pass or fail per criterion
- Agree corrective actions and timelines
- Regulatory and compliance checkpoints
- Open issues and blockers
- Confirm readiness timeline to acceptance gate
- Formal acceptance decision and signatory capture
- Agree immediate remediation actions
- Agree quarter roadmap and next checkpoints
- Incumbent system wind-down verification
- Agree remediation plan for any failed criteria