Pilot, packaging and readiness.
How an evaluation becomes a pilot, what is rented with what, and how far each capability is along today, including what needs a partner and what is not supported.
How a pilot runs
Five steps, each agreed with you; the scope and success criteria are written down before any work starts.
Review your use case
Your products, markets, licence and the partners you already have or need. We say plainly what the platform covers and what it does not.
Map modules and integrations
Which products you would rent, and what connects from outside: your sponsor bank or PSP, your providers, your own systems.
Agree scope, responsibilities and success criteria
Written down before work starts: what is configured, who does what, and how both sides will judge the result.
Configure and demonstrate
Your products, policies and flows set up on the platform and shown working, with test data.
Review the results
Against the criteria agreed in step 3, including the gaps found and what closing them would take.
What a pilot produces
Written outputs, so the decision after the pilot rests on what was shown, not on a presentation.
Module and dependency map
The products you would rent, what each needs from Core and from the others, and the minimum setup.
Integration responsibilities
Each connection (sponsor bank or PSP, providers, your systems), who builds it and who runs it.
A configured evaluation scenario
Your product, policy or flow set up in a workplace and run with test data.
Agreed acceptance criteria
What both sides will check, fixed before the work starts.
Evaluation results
What was run, against which criteria, and what was observed.
Remaining gaps
What the platform does not cover for your case, and what closing each gap would take.
A proposal for the next stage
Scope, integrations and the conditions a production deployment would have to meet.
You supply
- Your use case: products, markets and volumes to plan for
- Your product terms, policies and the flows you want to see
- Test data, never real customer data
- Your licence position, and contacts at your sponsor bank or PSP where a payment rail is in scope
- People to evaluate the results and agree the criteria
Steinvar supplies
- A workplace on the platform with the products in scope
- Configuration of the agreed scenario, and a demonstration of it
- API definitions for the modules in scope
- The written outputs listed above
Outside the pilot
- Real customers or real money
- A live connection to a payment scheme, sponsor bank or PSP
- Migrating production data
- Certification, service levels or hosting commitments
- Regulatory approval, which stays yours
How a pilot is agreed. Its scope is set by the products and integrations in it, the scenarios to configure and the criteria to check. Whether a pilot is paid, its price and its length are agreed for each pilot, in writing, before it starts; there is no published pilot price.
Packaging
Seven products, rented per workplace. Steinvar Core is a bundle of five capabilities; the others are rented alongside it. Prices are not published: tell us your use case and we send a quote scoped to the products and volumes you need.
| Product | Includes | Needs from Core | Uses other products | From outside | Minimum to evaluate |
|---|---|---|---|---|---|
| Steinvar CoreBundle | Ledger, Save, Lend, Flow and Report in one rental: accounts and the general ledger with period close, deposits and savings, consumer loans, workflows and statements. | This is Core. Renting it needs the workplace’s BIC, institution code, country and default currency. | Steinvar Decide, for loan affordability on your own rule set (optional) | Credit-bureau data, if your lending needs it (not connected today) | Steinvar Core |
| Steinvar Payments | Transfers, standing orders, ISO 20022 messages and clearing envelopes, returns and recalls. | Payments move between Core’s accounts and post to its ledger. | Steinvar Screen, to screen both sides of each payment (optional) | Your sponsor bank or PSP for payments leaving the platform; connecting to it is integration work scoped per client | Steinvar Core + Steinvar Payments |
| Steinvar Verify | KYC and KYB policies, cases, document and chip checks, registries, ownership and enhanced due diligence. | Cases are opened for Core’s customers. | Steinvar Decide, if risk rating runs on your own rule set (optional) | Commercial ID verification, PEP and adverse-media data need a provider (not connected today) | Steinvar Core + Steinvar Verify |
| Steinvar Screen | Sanctions screening on every channel, transaction monitoring, two-person review of hits and alerts. | It screens Core’s customers and monitors their transactions. | Steinvar Payments, for real-time screening of each payment (optional) | None for the lists: EU, UN, OFAC, UK and Lithuanian lists are built in | Steinvar Core + Steinvar Screen |
| Steinvar FNTT Reporting | Suspicious-activity reports prepared for FNTT: cases, deadlines, MLRO approval and the filing recorded. | Reports are about Core’s customers and accounts. | Steinvar Screen, to open report cases from its monitoring alerts (a case can also be opened for a customer directly) (optional) | You file each report in FNTT’s own system with a qualified e-signature; the platform does not send it | Steinvar Core + Steinvar Screen + Steinvar FNTT Reporting |
| Steinvar Docs | Documents, contracts, approvals, simple e-signatures with sealed evidence, its own API and webhooks. | Documents, folders and contracts are its own records, with its own API; customers sign in e-banking as Core’s customers. | — | Qualified e-signatures need a provider (not connected today) | Steinvar Core + Steinvar Docs |
| Steinvar Decide | Staged decision rule sets, sandbox evaluation, approval and evaluation records. | Its rule sets are used by Lend (affordability) and Verify (risk rating), both on Core’s customers. | — | — | Steinvar Core + Steinvar Decide |
| Steinvar NotifyIncluded | Approved message templates; e-mail, SMS, Slack and in-app delivery with a log. | Part of every workplace; not rented. | Your own SMTP server and SMS gateway account | — | |
Every setup here starts with Steinvar Core, because the other products work on its customers, accounts or ledger. Renting does not check this; whether a product can be bought without Core is agreed case by case.
What a workplace is
A workplace is one branch of your company on the platform. An approved registration creates your organisation, your company and its head-office branch as the first workplace, with its first administrator; a company can add branches. Products are rented per workplace, each workplace has its own prepaid balance, and staff access is granted to one workplace, to all of a company’s, or across the organisation.
How charges arise
- Products are rented per workplace, monthly or annually; renting or releasing one switches its services and screens on or off.
- Some operations, such as payments, carry a per-use fee taken from the workplace’s prepaid balance; when it runs out, those operations stop until it is topped up.
- Payment details are not needed to register. Money is charged only when you top up the balance by card.
The sandbox
For evaluation only, on test data, and not connected to a payment system. You register with a work e-mail, confirm it with a code, and we review the registration; you can sign in once it is approved. There are no service levels, and a sandbox unused for 90 days may be closed. Terms
A scoped quote
Send an enquiry with the products you are considering and your expected volumes. We answer with the packaging that fits and, where per-use fees apply, how they are measured.
Readiness
What you can evaluate today, what is agreed only within a pilot, what depends on an outside provider, what is planned and what is not supported. Planned items carry no date.
Available for evaluation
- CoreMulti-currency accounts, holds, limits and arranged overdrafts
- CoreDouble-entry ledger, month close, year end and trial balance
- CoreTerm deposits and savings products
- CoreConsumer loans: affordability, agreements, servicing, collections, IFRS 9
- CoreWorkflows with maker-checker versions and dry runs
- CoreCustomer statements in PDF and camt.053
- ChannelsCustomer e-banking (web) with strong customer authentication
- ComplianceKYC and KYB policies and cases
- ComplianceSanctions screening and transaction monitoring
- ComplianceSuspicious-activity reports prepared for FNTTFiled by you in FNTT’s system
- OperationsDocuments and simple e-signatures
- OperationsDecision rule sets
- OperationsRegulatory return formats (CRS, CESOP, Bank of Lithuania, VMI)Generated for you to submit
- PaymentsISO 20022 messages and clearing envelopes
Within an agreed pilot scope
- DeliveryYour products, policies and flows configured on the platform
- DeliveryGaps found during evaluation, prioritised on a shared roadmap
Needs an external provider or integration
- PaymentsSEPA Credit Transfer and Instant, liveThrough your sponsor bank or PSP
- PaymentsCard issuing and processingThrough a card processor; card records only today
- ComplianceCommercial ID-verification, PEP and adverse-media data
- LendingCredit-bureau data
- OperationsQualified electronic signatures
Planned
- PaymentsVerification of Payee, SEPA Direct Debit, SWIFT
- ChannelsPSD2 access for third-party providers
- OperationsReturns built from the ledger, AnaCredit, COREP/FINREP, deposit-guarantee single customer view
- OperationsDORA registers and incident reporting
Not supported
- LendingMortgages, collateral and guarantors
- ComplianceFraud detection beyond limits, screening and monitoring scenarios
- ComplianceLiveness and face matchingSwitched off until calibrated
- ChannelsPush notifications to mobile apps
How it is operated today
Kept apart from the features above: whether something exists is a different question from how it is run.
- Hosting
- One host at OVHcloud in Gravelines, France (EU). There is no second site and no automatic failover; event streams run as a single replica.
- Backups and recovery
- Nightly database and ledger backups; a restore drill of the core passed on 22 October 2026.
- Monitoring
- Health and readiness checks, metrics and traces on every service, with alerts that reach the operations team.
- Certification
- No SOC 2, ISO 27001 or PCI DSS certification is held.
- Payment connectivity
- No live connection to a payment scheme; payments run through the sponsor bank or PSP you bring.
- Your part
- Your licence, your regulatory filings and your own review of whether the configuration meets the rules that apply to you.
Identities, access, data and audit: Trust and security
From evaluation to production
The operating conditions above are how the platform runs today. A production deployment is agreed separately, and anything it requires beyond them, such as a second site, a certification, a service level or a live payment connection, is a condition to meet before go-live, not something already in place.
Results and proposal
The pilot’s results, its remaining gaps and a proposal for production scope.
A production agreement
Terms, prices, service levels and responsibilities, agreed in writing for your deployment.
Conditions met before go-live
The integrations built and tested, your regulatory approvals in place, and any operating requirement your regulator or partner sets checked against how the platform is run.
Go-live
Only once those conditions are met; nothing above is in place before it is agreed.
Start with your use case.
Or open the sandbox and look on your own.