Solaris SEPA Instant Go-Live: A First-Phase Control Plan

Solaris has gone live on ACI Connetic for SEPA Instant payments and completed the first phase of a broader payments-modernization initiative. ACI Worldwide's release says the scheduled move consolidated Solaris's SEPA Instant infrastructure onto its cloud-native platform. That is a defined production milestone: the programme has advanced from the platform selection announced in September 2025 to a first-phase go-live. It is not evidence that every planned migration, market, rail, partner connection, or pan-European objective is complete. For operators, that distinction sets the agenda. The launch closes a project phase, but it opens the period in which live controls must produce dependable evidence under real operating conditions.

The parties bring a specific scope to that milestone. Solaris is described as a licensed German bank and embedded-finance platform supplying accounts, cards, lending, and payments to fintechs, digital brands, and multinationals. ACI describes Connetic as combining payment processing, orchestration, fraud prevention, and payments intelligence. Those descriptions explain why the migration touches more than a technical endpoint: processing decisions, control signals, records, and partner responsibilities can meet within one operating chain. Yet they remain descriptions of platform capability and business role. The reviewed evidence does not independently establish the implementation's throughput, uptime, resilience, fraud-loss performance, cost, or customer effect.

Phase one therefore needs a written boundary before it needs a success narrative. The operating record should identify which inbound and outbound payment flows are live, which counterparties and partner dependencies they use, which exception types can be handled, and where reconciliation begins and ends. It should also list every flow still running elsewhere or deferred to a later phase. A clean scope map prevents teams from treating platform availability as universal migration. It also gives risk, support, finance, compliance, and engineering teams the same answer when an incident crosses systems. If the boundary cannot be shown through current configuration, ownership records, and tested procedures, the phase is not yet legible enough to expand.

The regulatory context raises the standard for that operating record. The European Central Bank's summary of the Instant Payments Regulation says relevant payment service providers must offer sending and receiving of instant euro transfers. Charges cannot exceed those for comparable standard transfers, verification of payee must be offered free to the payer, and instant-payment providers must perform periodic sanctions checks. For the euro area, receiving and equal-charge requirements applied from 9 January 2025, while sending and verification-of-payee requirements applied from 9 October 2025. These are official obligations in the operating environment; they are not proof that this specific Solaris implementation satisfies every requirement in every case.

That difference between regulatory duty and implementation evidence should shape the control plan. Each obligation needs a named control owner, a source of truth, a test method, and retained evidence. The team should know which system records a verification-of-payee result, where a payer-facing exception is routed, how pricing parity is checked, and how periodic sanctions screening is evidenced. These are recommended governance questions, not disclosed details of the Solaris deployment. A first-phase sign-off should show how the live service supports the relevant obligation and who investigates a control failure, rather than relying on the existence of a capable platform as a substitute for implementation assurance.

The first operational layer is around-the-clock monitoring. SEPA Instant operations do not become ready merely because a release completed on schedule. Solaris and ACI need an agreed view of service health, queue depth, transaction latency, failure codes, partner availability, and unresolved exceptions across the live scope. Dashboards are useful only if thresholds produce an owned response. Every alert class should identify the first responder, the time allowed for acknowledgement, the route for escalation, and the evidence preserved when the alert clears. The reviewed sources do not disclose those thresholds or service outcomes, so no particular availability or response level should be inferred from the go-live announcement.

Incident ownership must then connect technical recovery with customer, partner, and regulatory communication. A processing interruption may begin in one system but appear as a delayed instruction, a rejected transfer, a mismatched status, or an unexplained balance elsewhere. The incident model should establish who opens the record, who declares severity, who coordinates ACI and other dependencies, and who decides whether to restrict a flow. It should also name the owner of external communication and the person who closes the event after reconciliation confirms the final state. One shared timeline, with decisions and evidence attached, is more defensible than separate technical and business narratives assembled after the fact.

Fraud prevention and verification of payee require their own queues because a control can protect one objective while creating another risk. A warning, mismatch, suspected fraud signal, or sanctions-related result may require a pause, review, customer explanation, or formal escalation. Operators should define what can proceed automatically, what needs manual judgment, what information the reviewer may use, and when the case must stop. They should track false positives and overrides without assuming that either metric alone shows control quality. A low intervention rate could reflect precision or missed risk; a high rate could reflect caution or excessive friction. The release provides no measured fraud or payee-verification outcomes.

Reconciliation is the point where a successful message must become a defensible financial record. Phase one should connect each payment instruction with its processing status, settlement evidence, ledger treatment, and any customer-facing state. Breaks should enter a controlled queue with an age, cause category, owner, and next action. Duplicate, delayed, rejected, incomplete, and unmatched items may require different responses, and a cleared technical alert does not automatically close the accounting question. The first-phase scorecard should therefore report reconciliation timeliness and outstanding breaks separately from platform availability. Neither the go-live announcement nor the earlier selection release discloses exception or reconciliation performance.

Cutover evidence should remain available after the implementation team disperses. A defensible file would preserve the approved scope, readiness checks, test results, change record, decision authority, live validation, known limitations, and outstanding actions. The rollback record should state what conditions would have triggered reversal, who could make that decision, which prior state could be restored, and how transactions created during the transition would be accounted for. A successful scheduled go-live means the announced milestone occurred; it does not establish that every fallback was tested or that every cutover risk was eliminated. Retaining the evidence makes later review possible without rewriting history from memory.

Vendor and partner accountability should be expressed through one operating matrix rather than scattered contracts and contact lists. Solaris may own the customer relationship and regulated obligations while ACI operates important platform capabilities, but the reviewed material does not disclose their detailed division of responsibility. The matrix should cover monitoring, configuration, fraud rules, payee-verification handling, incident command, recovery, reconciliation support, evidence retention, and change approval. Other dependencies in the live flow should be included as well. A responsibility is not controlled merely because two parties can both act; the model must identify who decides, who executes, who is consulted, and who supplies proof.

A staged 30-day review can turn the announcement into an operating baseline. During the first three days, the team should validate scope, confirm monitoring coverage, inspect open exceptions frequently, and preserve every material incident and override. From days four through fourteen, it should classify recurring failures, reconciliation breaks, false positives, review times, and partner escalations. From days fifteen through thirty, it should compare those patterns with agreed thresholds, retest recovery and communication paths, and close or assign every control gap. This sequence is an operator proposal, not a Solaris or ACI commitment. Its purpose is to make first-phase performance inspectable before routine operation obscures launch-period weaknesses.

The measurement set should remain compact enough to drive decisions. Volume shows the workload observed, not success by itself. Latency should be read with failure and timeout rates; availability should be read with incident duration and recovery quality; fraud alerts should be read with confirmed outcomes, false positives, overrides, and review time. Reconciliation needs aged breaks, unmatched items, duplicate handling, and time to final resolution. Customer or partner contacts can reveal unclear statuses even when infrastructure measures look normal. None of these measures has been published for the deployment. They are the evidence Solaris would need internally before claiming that live operation is controlled or that expansion is justified.

Expansion should pass explicit gates rather than follow the momentum of a completed launch. A gate can require sustained performance within approved latency, failure, availability, reconciliation, and fraud-control thresholds; no unresolved high-severity incident; tested recovery; clear partner obligations; and closed audit actions. The next rail, market, or partner should also receive its own scope and dependency review because phase-one evidence may not transfer unchanged. This staged discipline parallels the readiness questions in the related businesstalky coverage of ISO 20022 settlement controls, staged B2B digital-rail development, and governance of payment-link proposals. Those articles remain distinct topics, while the present analysis is specifically about Solaris SEPA Instant payments in production.

The remaining unknowns are material. The sources do not report transaction volume, throughput, uptime, migration duration, implementation cost, fraud losses, exception rates, verification-of-payee accuracy, reconciliation performance, or customer outcomes. They do not establish delivery of the planned pan-European platform, and they do not provide the detailed allocation of operational responsibility between Solaris and ACI. Product resilience and performance descriptions remain vendor statements until measured separately. These gaps do not negate the go-live. They define what the announcement cannot support and what a responsible 30-day review should seek to establish without publishing assumptions as results.

The operating conclusion is deliberately narrower than a transformation claim. Solaris has moved its SEPA Instant infrastructure onto ACI Connetic on schedule and completed the first phase identified in the announcement. The next proof is not another capability description. It is a body of live evidence showing that monitoring, fraud and payee controls, reconciliation, incident recovery, partner coordination, and regulatory records remain controlled around the clock. Until that evidence is measured and reviewed, the strongest defensible position is also the most useful: treat go-live as the start of operational assurance, and let phase-one results determine whether broader modernization can proceed safely.

A first-phase go-live proves that the migration reached production; it does not prove the broader programme, resilience, control performance, or customer outcomes until live evidence establishes them.

Published September 25, 2026 · Source event September 24, 2026