Frequently asked questions

Artabos Rail is a containerised middleware layer that connects SAP ERP systems to Keeta settlement infrastructure. It translates standard ISO 20022 payment messages (pain.001) into Keeta network transactions, and translates Keeta ledger events back into bank-format statements (camt.053) that SAP can import via FF_5. To your treasury team, Keeta looks like one more bank connection — nothing in their process changes. See how it works.

Keeta is a settlement network designed for regulated financial transactions. It provides on-chain fiat currencies (USD, EUR, GBP) issued by licensed entities, real-time settlement finality, and identity verification at the protocol level. Artabos Rail uses Keeta as the settlement layer while presenting standard banking interfaces (ISO 20022) to the enterprise systems that initiate and reconcile payments.

The primary use case is intercompany transfers where treasury controls both the sending and receiving entities. This is the lowest-risk starting point because both sides are within the same corporate group. From there, Artabos Rail extends to supplier payments through a managed onboarding process (request, approve, verify). Multi-entity support allows a single deployment to manage payments across multiple legal entities, each with their own accounts and compliance rules.

Artabos Rail integrates with SAP through standard file-based payment interfaces. SAP exports pain.001 files through its normal payment run process. Artabos Rail watches a designated directory, parses the files, executes settlements on Keeta, and generates pain.002 status reports and camt.053 end-of-day statements. SAP imports these statements via the FF_5 transaction, the same way it imports statements from any other bank. No SAP customisation, ABAP development, or IDoc configuration is required.

Artabos Rail supports the full payment lifecycle in ISO 20022: pain.001 (Credit Transfer Initiation) for inbound payments, pain.002 (Payment Status Report) for real-time status feedback, camt.053 (Bank-to-Customer Statement) for end-of-day reconciliation, camt.054 (Debit/Credit Notification) for individual confirmations, camt.052 (Intraday Report) for real-time position monitoring, and camt.055 (Cancellation Request) with camt.029 resolution responses. BAI2 output is also supported for US corporate treasury systems.

Minimal. You configure Keeta as a new house bank in SAP (the same way you would add any correspondent bank), point the payment file output to the Artabos Rail inbox directory, and set up FF_5 to import statements from the outbox directory. No custom ABAP, no middleware connectors, no IDoc mappings. Your treasury team uses the same transactions and processes they already know.

Our target is 100% auto-match in SAP FF_5 reconciliation. This is achieved by echoing the original EndToEndId from each pain.001 transaction into the corresponding camt.053 statement entry — the primary key SAP uses for automatic matching. Statement continuity is maintained with gapless sequence numbers and carried-forward opening balances, matching the behaviour of traditional bank statements.

The customer always holds the signing keys. Artabos Rail is designed so that cryptographic key material never leaves the customer's infrastructure. Keys can be stored in a hardware security module (HSM), a cloud key management service (AWS KMS, Azure Key Vault, GCP Cloud KMS), or any signing infrastructure the customer already operates. A compromised Artabos Rail instance cannot move funds without the customer's cryptographic authorisation.

Artabos Rail implements four-eyes approval through Keeta's protocol-level co-signing. The system acts as a required co-signer on the customer's account, enforcing payment policies (amount limits, velocity checks, counterparty validation) before releasing its signature. This is enforced at the cryptographic protocol level, not the application layer. A bug in the approval logic can only fail to release a payment, never release an unauthorised one.

Idempotency is enforced at multiple levels. Each payment file is fingerprinted on ingestion — resubmitting the same file is detected and rejected. Each individual transaction carries an EndToEndId that serves as a deduplication key in the database. At the network level, Keeta's idempotent block submission prevents duplicate settlement even in retry scenarios. The system is designed to prefer a stuck payment over a duplicated one.

Yes. Artabos Rail includes built-in sanctions screening that can run against a local database or an external screening API. The system fails closed — if the screening service is unavailable, payments are held rather than released. Every screening result is recorded in the immutable audit log with the payment it applies to.

Artabos Rail runs entirely in the customer's own infrastructure. It ships as a Docker container image with a Helm chart for Kubernetes deployment. Customers can run it on-premise, in their private cloud, or in any managed Kubernetes environment. Payment data never leaves the customer's tenancy. Artabos has no access to the running system, the database, or the transaction data.

Shadow mode lets you run Artabos Rail alongside your existing bank connection without actually executing settlements. Every payment file is parsed and processed through the full pipeline — IBAN resolution, limit checks, compliance screening — but no Keeta transactions are submitted. This lets your treasury team compare Artabos output against incumbent bank statements side-by-side before cutting over, eliminating adoption risk entirely. Try the payment parser demo to see the pipeline in action.

The operator console is a built-in web interface for monitoring and managing payment operations. It provides real-time dashboards with payment status distribution, success rates, and activity feeds. Operators can drill into individual payments to see their full lifecycle — from SAP file ingestion through Keeta settlement to statement generation — with clickable links to the Keeta block explorer for on-chain verification. Role-based access control (viewer, operator, admin) ensures appropriate permissions.

Failed payments are recorded with full diagnostic detail in the audit log and reported back to SAP via pain.002 status reports. Operators can inspect failures in the web console, which shows the exact step where the payment stopped (parsing, resolution, submission, or confirmation). Operators can retry failed payments, skip them permanently, or release limit-breached payments through the console or CLI. Every operator action is recorded in the immutable audit log.

For a typical corporate with 40 million EUR in annual intercompany transfers, the FX spread savings are approximately 600,000 EUR per year. Traditional correspondent banking charges 50 to 300 basis points in hidden FX spread on cross-currency payments. Artabos Rail records the executed rate against every transaction and logs a cost comparison versus your incumbent bank, making the savings transparent and auditable. See the full feature overview.

Contact us to schedule a technical walkthrough. We will map your current SAP payment flows, identify the settlement corridors where savings are highest, and set up a shadow-mode pilot that runs alongside your existing bank connection with zero risk to production payments.