Steinvar PaymentsTransfers and SEPA formatsScreened, limited and approved before it books.
Steinvar Payments takes a transfer from e-banking, the back office or an API, screens both parties, checks the customer’s limits and second factor, and books it once. Standing orders run on the right business day, and ISO 20022 messages are built for the clearing systems your sponsor bank or PSP connects to.
Customer e-banking, from its demo bank; names are blurred.
- 13
- ISO 20022 message types: pacs, pain and camt
- Once
- per Idempotency-Key, on every money route
- 2 parties
- screened against sanctions lists in real time
Transfers
Exactly once
Every money route requires an Idempotency-Key, and each payment moves through a compare-and-set lifecycle, so a retry never pays twice.
Four-eyes in the back office
A payment an employee enters waits in an approval queue for a second employee.
Strong customer authentication
A customer confirms each payment with a code bound to its amount and payee; passkeys and lockout come with it.
Screening and limits
Debtor and creditor are screened by name in real time with a minimum score, and the customer’s per-payment, daily, monthly and velocity limits apply.
Standing orders
Any schedule
Once on a later day, or weekly, monthly, quarterly or yearly until an end date, a count or cancellation.
Confirmed once
Setting an order up takes one code bound to the account, payee, amount and schedule; the payments that follow need none.
On the business day
A payment falling on a weekend or holiday moves to the next business day by the workplace’s holidays and the currency’s settlement days (TARGET2 for the euro).
Paid once, or held
Each payment is its own journal entry. Refused ones are retried and then recorded as missed with the customer told; one of unknown outcome waits for an employee.
Messages and formats
ISO 20022
pacs.008, pacs.002, pacs.004 and pacs.028; pain.001 and pain.002; camt.027, camt.029, camt.052, camt.053, camt.054, camt.056 and camt.087, between JSON and XML.
Clearing envelopes
CENTROlink, TIPS, Bundesbank and intra-group envelopes for SEPA Credit Transfer and Instant, with XSD validation and XAdES signing.
Returns and recalls
R-transactions and teller actions handled once each, with a claim on every action.
Reference data
IBAN validation by mod-97 and per-country structure, BIC lookups, exposed to every service over gRPC.
How a payment moves
Request
E-banking, the back office or an API sends the payment with its Idempotency-Key.
Confirmation
The customer confirms with a code bound to amount and payee; an employee’s payment waits for a second employee.
Checks
Screening of both parties, limits, balance less holds, account status and the business date.
Booking
The ledger posts it once; an external payment is handed to the rail as an ISO 20022 message.
Controls built in.
Approval queue
HQ payments are maker-checker: the employee who enters one cannot approve it.
Payment codes
A code is valid for one amount and one payee; changing either needs a new code.
Recorded refusals
A refused payment carries a stable reason code that operations and the customer see.
Standards and formats
- ISO 20022
- SEPA SCT
- SEPA Instant (TIPS)
- CENTROlink
- XAdES
- TARGET2 calendar
- PSD2 SCA
Not in this module today
- No live clearing connection: messages reach SEPA through your sponsor bank or PSP, which is chosen per client.
- SEPA Direct Debit, SWIFT and Verification of Payee are on the roadmap.
Questions about Steinvar Payments
Does Steinvar connect to SEPA directly?
Not today. It builds and parses the ISO 20022 messages and clearing envelopes; the connection to the scheme runs through your sponsor bank or PSP.
Can customers schedule payments?
Yes, as standing orders: once on a later day or on a weekly to yearly schedule, confirmed once with a code, and paid on the business day.