Every payment file triggers a precise sequence of parsing, compliance checks, on-chain settlement, and statement generation. Here's exactly what happens at each step.
The raw file is hashed. If this file was already processed, it's rejected immediately. No duplicate payments can enter the pipeline.
IdempotentEach payment is extracted into a format-agnostic canonical model. For pain.001: debtor/creditor IBANs, BIC, amounts. For ACH: ABA routing numbers, account numbers, SEC codes. For IDoc: vendor master data. The EndToEndId is preserved as the primary reconciliation key.
Creditor and debtor names and identifiers are checked against OFAC SDN (US) and EU consolidated sanctions lists. The OFAC list is synced directly from Treasury.gov. Fails closed: if the screening service is unavailable, the payment is blocked.
EU payments: IBAN is resolved to a Keeta keeta_a... address via the entity registry. US payments: ABA routing + account number maps to bank-account:us for anchor-mediated payout. The anchor knows the linked bank details from KYB onboarding.
Creditor identity is checked against onboarding records. If the creditor's PartyId (BIC, LEI, org ID) doesn't match what was registered, the payment is flagged. Verified at onboarding, monitored per payment.
Per-transaction amount limits, daily aggregate limits, and hourly velocity checks. A payment that breaches any limit enters LIMIT_BREACHED state and requires manual release via the operator console.
When the payment currency differs from the settlement currency (e.g. EUR payment settling in $USD), Artabos requests a binding quote from the Keeta FX anchor. The quote is cryptographically signed and has a time-limited validity window.
The anchor's executed rate is compared against the bank benchmark rate configured per currency pair. The spread difference is logged per payment for the cost savings report that makes the business case at renewal time.
All send operations with the EndToEndId carried in the external field are packed into one block — one signature, one micro fee, regardless of how many payments.
The block is transmitted to the Keeta network. If a conflict is detected (another block was published concurrently), Artabos automatically recovers by rebuilding and retransmitting against the latest account state.
Auto-recoveryArtabos monitors the block until it receives permanent votes from the network's representatives. Once finality is reached, the settlement is irreversible and cryptographically guaranteed. The payment transitions to CONFIRMED.
The anchor monitors for incoming transfers. When it detects a payment to a destination linked to a bank account, it initiates the off-ramp. For US payouts, the anchor uses the recipient's routing number, account number, and account type. For EU payouts, it uses IBAN, BIC, and beneficiary details. All bank details are provided by the recipient during KYB onboarding.
bank-account:us bank-account:iban-swift KYB verifiedThe anchor reports transfer status back to Artabos. Only a completed status is terminal — everything else is treated as in-progress. Artabos polls until completion or failure.
If the receiving bank rejects the payment (R01 Insufficient Funds, R02 Account Closed, R03 No Account, etc.), the anchor reports failure. Artabos maps the return reason code and transitions the payment to RETURNED. Notification of Change codes (C01–C07) are flagged as correctable.
Generated immediately after file processing. Reports acceptance or rejection status for each payment in the file. The original MsgId is echoed. SAP imports this to update payment status.
Emitted per payment on finality confirmation. Each notification carries the EndToEndId for precise matching. Enables real-time visibility in SAP before the end-of-day statement arrives.
Triggered automatically when Keeta account state changes. Contains all confirmed payments for the day with correct opening/closing balances, gapless sequence numbers, and echoed EndToEndId values. SAP imports via FF_5. US corporates receive BAI2 format instead.
Available on demand for real-time position monitoring. Same format as camt.053 but without the end-of-day finality semantics.
If the ERP sends a camt.055 cancellation request, Artabos processes it and responds with camt.029 indicating whether the cancellation was accepted, rejected, or pending.
Same pipeline, different message formats and bank account types. The canonical model in the middle abstracts the differences.
| Payment file | pain.001 (ISO 20022) |
| Account identifier | IBAN + BIC |
| Keeta anchor type | bank-account:iban-swift |
| Anchor fields | IBAN, BIC, country, beneficiary name |
| On-chain currency | $EUR, $GBP |
| Statement output | camt.053 / MT940 |
| Status report | pain.002 |
| Sanctions list | EU Consolidated |
| Payment file | NACHA ACH (CCD/CTX/PPD) |
| Account identifier | ABA routing + account number |
| Keeta anchor type | bank-account:us |
| Anchor fields | Routing number, account number, account type |
| On-chain currency | $USD |
| Statement output | BAI2 |
| Status report | pain.002 / ACH return (R01–R85) |
| Sanctions list | OFAC SDN |