Banking · payments · AI decision support
Railspan.
Banking, connected.
Decisions, explained.
Bring accounts, lending, card issuing, payments and daily operations into one proposed banking workspace. Give teams an AI decision manager to examine current evidence, explain risk and compare the next step before acting.
Proposed product · Synthetic examples · Integrations and production delivery remain scoped work
Your brand / One operating experience
A common experience with explicit system ownership. Each connection requires an implemented and tested adapter.
AI decision manager / Proposed product layer
Before you decide,
see what the evidence says.
Ask a practical question. Check the source data, policy and trade-offs. Compare a safer plan, then prepare a decision for the right approver. The intended live workspace uses authorized event feeds; this demonstration uses fixed synthetic snapshots and scripted explanations.
Static sample: the full batch leaves USD 250,000, below the sample USD 300,000 floor. Enable JavaScript to compare plans and prepare a simulated review note.
The evidence
Fixed snapshot · 23 Oct 2026, 16:00 GSTCan we release this settlement batch and preserve the operating buffer?
- Available cash
- USD 1,200,000
- Existing reservations
- USD 300,000
- Proposed release
- USD 650,000
- Buffer after release
- USD 250,000
Sample policy / Not a regulatory threshold
Retain at least USD 300,000 after existing reservations and the proposed release.
Source trail
- DEMO-CASH-01Treasury snapshot · sample available cash
- DEMO-HOLD-02Ledger reservations · sample committed funds
- DEMO-BATCH-03Settlement queue · proposed batch
A production check needs source timestamps, processing watermarks, matching business dates and permission checks. A recent screen refresh alone does not establish current data.
Decision support / Explanation + deterministic checks
Compare the plan before release.
Sample buffer falls below policy
The full batch would leave USD 250,000. That is USD 50,000 below the sample floor. Compare a smaller release or replenish the available funds.
1,200,000 − 300,000 − 650,000 = 250,000
Next owner: Treasury lead. A bank-authorized reviewer must confirm the funds, policy and proposed action.
A review note is not approval or execution. No funds, loans, cards or messages are created here.
Read the right data
Connect ledger events, core records, processor status and approved documents. Show what is current, missing or restricted.
Make the trade-off visible
Explain assumptions, run deterministic calculations and compare options. Missing evidence stops a recommendation.
Keep authority explicit
Record model and policy versions, sources, reviewer and rationale. Separate analysis, approval, execution and verified outcome.
The banking operating model
From the first application
to the daily close.
A bank needs more than a core and a payment gateway. Railspan’s proposed scope connects the customer journey to product rules, financial records, risk decisions and the people accountable for each outcome.
Foundation available means a reviewed upstream building block exists. Integration required and New product layer identify proposed Railspan work. These labels do not describe live customer capabilities or regulatory approval; each product and market needs implementation and observed acceptance.
01 / Integration required
Customer onboarding, KYC and KYB
Help individuals and businesses complete an application, supply evidence and understand what needs review before an account can open.
Foundation & delivery gap
Foundation: Fineract customer records and document support; proposed identity and business-verification adapters
Work to complete: Identity, beneficial ownership, eligibility, screening and periodic review need selected providers, local policies and accountable reviewers. Storing a document is distinct from verifying it.
Reviewed source ↗02 / Foundation available
Accounts, savings and deposits
Give customers a clear view of their account activity while staff manage approved product terms, interest, fees and account changes.
Foundation & delivery gap
Foundation: Apache Fineract 1.x configurable savings products, account lifecycle and accounting APIs
Work to complete: Configure and validate each deposit product, funding route, statement and accounting rule. Agree one authoritative balance owner and the institution's deposit-taking permissions.
Reviewed source ↗03 / New product layer
Loan origination and servicing
Guide an applicant through evidence, eligibility, an explainable credit decision and offer acceptance, then maintain the agreed loan and repayment journey.
Foundation & delivery gap
Foundation: Fineract loan products, applications, schedule calculation, approval/disbursement commands and servicing
Work to complete: Complete origination, bureau/affordability checks, underwriting policy, documents and decision governance are additional work. An approval API is not a credit policy; AI recommendations require authorized decision ownership.
Reviewed source ↗04 / Integration required
Card issuance and lifecycle
Let an eligible customer receive a virtual or physical card, manage its status and limits, review purchases and raise a dispute.
Foundation & delivery gap
Foundation: Proposed issuer/processor integration; official issuing documentation provides the lifecycle reference
Work to complete: Select the issuer program and market, onboard cardholders, arrange funding and implement card controls, authorization, clearing and disputes. Acceptance SDKs and the eight foundations do not themselves issue cards.
Reviewed source ↗05 / Foundation available
Card and merchant payment acceptance
Give merchants a consistent checkout and let operations trace payment attempts, processor outcomes, refunds and unresolved exceptions.
Foundation & delivery gap
Foundation: Hyperswitch payment connectors, routing and checkout integration foundation
Work to complete: Acquire provider access and validate supported operations, authentication, disputes, callbacks and PCI responsibilities for the selected market. Reconcile unknown outcomes before any retry.
Reviewed source ↗06 / Integration required
Domestic and international payments
Capture a beneficiary and payment instruction, validate its data, show fees and status, then reconcile the outcome across the contracted route.
Foundation & delivery gap
Foundation: Hyperswitch routing; optional Mojaloop scheme operations; proposed ISO 20022 adapters
Work to complete: Each route needs bank/network access, message profiles, screening, cutoffs, returns and settlement agreements. International corridors also need FX and correspondent/provider arrangements; an ISO message does not move money.
Reviewed source ↗07 / New product layer
Treasury and liquidity operations
Help treasury staff see available funds, reservations and settlement obligations before approving a funding or liquidity action.
Foundation & delivery gap
Foundation: TigerBeetle pending/posting primitives and Mojaloop participant-position concepts
Work to complete: Build bank-balance ingestion, forecasts, limits, funding approvals and FX/exposure views. Distinguish internal ledger positions from externally confirmed funds and settlement-bank balances.
Reviewed source ↗08 / New product layer
Fraud, AML and sanctions decisions
Bring alerts and permitted evidence into a decision queue so qualified teams can investigate, explain a decision and track follow-up.
Foundation & delivery gap
Foundation: Proposed decision-manager workspace with selected fraud, screening and monitoring services
Work to complete: Detection models, lists, monitoring, regulatory reporting and jurisdiction-specific policies require separate providers and governance. AI can organize evidence and suggest actions; credit, AML and financial decisions retain named authority.
Reviewed source ↗09 / Integration required
Reconciliation and finance close
Match external evidence to account and ledger records, assign breaks, review adjustments and retain the evidence behind a business-date close.
Foundation & delivery gap
Foundation: Fineract accounting/COB building blocks; TigerBeetle transaction records; proposed reconciliation layer
Work to complete: Agree account mappings, authoritative balances, business dates, suspense, reversals and sign-off. Cross-system matching and close acceptance remain implementation work; an internal entry is not proof of external settlement.
Reviewed source ↗10 / New product layer
Customer service and collections
Give service teams the customer's issue, repayment context and accepted owner together, with reviewed messages and a clear route to resolution.
Foundation & delivery gap
Foundation: Fineract servicing and selected billing-engine overdue operations; proposed Relay integration
Work to complete: Connect permissioned case/account views, collection strategies, hardship treatment, communication consent and escalation. Select one invoice owner per billing domain; AI summaries do not authorize account changes or collections actions.
Reviewed source ↗11 / Integration required
Governance, reporting and security
Help staff work within their role, reviewers follow an audit trail and leaders see the operational evidence behind reports and release decisions.
Foundation & delivery gap
Foundation: Fineract permissions, command audit and reporting concepts; proposed platform-wide control layer
Work to complete: Unify tenant roles, enterprise identity, approvals, audit retention, security monitoring, recovery and regulatory-report definitions. Shared controls and certifications do not follow automatically from component selection.
Reviewed source ↗12 / Foundation available
Open banking and consent
Let a customer grant appropriate access, understand its scope and revoke it while staff can trace which application used permitted bank data.
Foundation & delivery gap
Foundation: Open Bank Project APIs, consent controls and entitlement model
Work to complete: Implement bank connectors, identity journeys, scope enforcement, revocation and the selected local standard. API support is separate from bank access, regulatory authorization and conformance acceptance.
Reviewed source ↗AI fraud & risk engine / AI credit engine
Understand the signal.
Explain the decision.
Two proposed engines, with different jobs. Fraud operations investigates suspicious behaviour and payment exposure. Credit teams assess applications and portfolio risk. Both need validated data, versioned policies and accountable decisions.
Protect transactions & accounts
AI Fraud & Risk
New product layer- Rules and policy controls
Combine approved transaction/account signals with versioned rules. Show which condition matched, its configured action and the policy owner before changing a control.
- Device, velocity and account relationships
Inspect permitted device signals, attempts over defined time windows and linked account/payment patterns. Missing data stays visible; a shared device or graph connection is evidence to assess, not proof of fraud.
- Model and anomaly assessment
Evaluate selected fraud models and unusual behavior against the relevant customer/payment context. Preserve model version, feature freshness and uncertainty; keep model scores separate from LLM summaries.
- Step-up and review routing
Recommend additional verification or a qualified reviewer using approved policy. Define response deadlines and safe fallback; actual blocks, holds or challenges require authorized integrations and controls.
- Investigator evidence workspace
Bring source references, event times, rule matches, model outputs and reviewer notes together. Keep access scoped to the investigation and retain the recorded rationale for each authorized action.
- Backtesting and drift monitoring
Replay versioned rules/models on representative historical outcomes without future-data leakage. Review false positives, missed fraud, customer friction and segment differences; monitor drift and approve changes or rollback with evidence.
The AI fraud and risk engine is a proposed Railspan product layer. The demo uses synthetic signals and illustrative policy outcomes; it runs no trained fraud model and makes no live risk action. Production work includes permissioned signals, model/vendor selection, validation, investigator controls and monitoring. LLMs can summarize sourced evidence, not establish fraud, settle an AML decision or independently authorize a financial action. No accuracy or loss-reduction result is claimed.
Try the fraud review example ↗Assess affordability & credit risk
AI Credit Decisioning
New product layer- Consented inputs and completeness
Collect authorized applicant, income, obligation and bureau/account inputs. Show consent, provenance, freshness and missing evidence so incomplete applications receive an appropriate next step.
- Eligibility and affordability policy
Apply the institution's approved eligibility and affordability rules to verified inputs and proposed terms. Make assumptions, calculation inputs and policy exceptions reviewable before recommending an outcome.
- Versioned scorecards and model integration
Connect a selected scorecard, bureau or validated model through a governed interface. Retain feature definitions, model/policy versions, thresholds and evaluation results for the intended lending product.
- Grounded reasons and explanations
Trace reasons to the rules and model outputs that actually influenced the decision. Validate reason-code mapping and customer wording; an LLM must not invent reasons, and feature attribution alone is not a causal explanation.
- Human credit authority
Give the authorized credit process the evidence and recommendation, with documented approval, referral and override authority. Retain the responsible decision-maker and rationale before passing approved terms to servicing.
- Portfolio, fairness and model monitoring
Track observed repayment outcomes, score performance, drift and overrides by cohort. Assess relevant group disparities with suitable data and uncertainty; independent review governs recalibration, limits and retirement.
The AI credit engine is proposed decision-support work, separate from Fineract's loan applications and servicing. Synthetic affordability examples are not underwriting decisions, validated scorecards or proof of fair lending. Consented data integrations, approved policy, model validation, reason-code testing and named credit authority must be implemented before live use. Fineract receives approved terms only through an authorized workflow; an LLM explanation does not grant credit or disburse funds.
Try the affordability example ↗Design and model-governance references
These references inform proposed functionality and validation. Vendor features and guidance are not evidence of an integrated Railspan model or of local regulatory compliance.
- NIST AI RMF — voluntary AI risk guidance ↗
- NIST AI RMF Playbook — measurement, drift and error assessment ↗
- Federal Reserve SR 26-2 — current US model-risk reference; applicability is institution-specific ↗
- Stripe Radar rules — vendor reference for signals, velocity and controlled actions ↗
- Stripe Radar risk insights — vendor reference for investigator context and related payments ↗
- Fairlearn — assessment across groups and uncertainty ↗
- SHAP — explaining model outputs; predictive explanations require careful interpretation ↗
- Fineract loan API — application and servicing foundation ↗
Products customers use every day
Loans and cards.
The whole lifecycle.
Carry the customer’s application through to servicing, exceptions and closure. The proposed experience joins the relevant provider, core-account and decision records without turning a button click into an assumed financial outcome.
Origination → underwriting → servicing
Lending, with the decision trail intact.
Build an origination layer around Fineract’s loan servicing foundation, with product-specific terms, document collection, bureau/provider adapters and the proposed credit engine.
- 01
Apply and provide evidence
Capture the requested product, applicant information, consent and required supporting records. Tell the applicant what is still missing.
- 02
Assess eligibility and affordability
Retrieve authorized identity, bureau and income evidence through selected integrations. Record data freshness, policy checks and unresolved exceptions.
- 03
Review the credit decision
Present policy results, reasons and any AI recommendation to the authorized decision process. Record the accountable approver, policy/model version and overrides.
- 04
Confirm the offer
Review approved terms, fees, schedule and disclosures with the customer; capture acceptance and required documents before disbursement.
- 05
Disburse and reconcile
Create the approved loan record and initiate disbursement only through an authorized provider. Reconcile the result before marking funds delivered.
- 06
Service, collect and close
Track repayments and arrears, review hardship or restructuring requests and reconcile accounting. Close obligations only after the institution's required checks.
Programme → card → transaction → dispute
Issuing, beyond card acceptance.
Connect a selected issuer processor for virtual or physical cards, account funding, cardholder controls and transaction operations. Country, programme and provider support define the deliverable.
- 01
Agree the card program
Select an eligible issuer/processor program, country, card type and responsible parties. Agree funding, program rules and operating controls.
- 02
Onboard the cardholder
Complete the program's required identity or business checks, eligibility and terms before requesting a card.
- 03
Issue and manage the card
Request a virtual or physical card through the approved processor. Handle delivery, activation, status, replacement and permitted card-detail access.
- 04
Control authorization
Apply approved limits and authorization policy, verify processor events and define timeout/fallback behavior. A model explanation does not authorize spend.
- 05
Reconcile transactions
Match captures, reversals, refunds and clearing records to holds and ledger entries. Authorization and capture are separate events.
- 06
Resolve service and disputes
Support lost-card controls and disputes with evidence, deadlines and ownership. Track processor outcomes before adjusting the customer's account.
ISO 20022 implementation scope
A message that validates.
A payment you can trace.
Map the business instruction, validate the receiving scheme’s rules and track the outcome through to reconciliation. ISO 20022 and ISO 8583 support different integration needs; the correct format depends on the contracted bank or rail.
Define the route before the message.
- 01
Agree the message profile
Choose the receiving bank or scheme, exact message version and its usage guidelines. Record mandatory fields and supported operations.
- 02
Map customer instructions
Map parties, accounts, amounts, references and remittance information without silently dropping or inventing data.
- 03
Validate and review
Apply schema, code-set and community business-rule checks. Route incomplete or policy-sensitive instructions for review.
- 04
Exchange and track status
Use an authorized connector; correlate acknowledgements, status reports and returns. Acceptance is distinct from settlement.
- 05
Reconcile and retain evidence
Match statements and notifications to payment and ledger records. Demonstrate the agreed profile; no ISO certification is claimed.
Proposed adapters and validation pipeline. This website does not run an XSD validator or connect to a payment network. Exact versions and usage profiles are selected with the receiving scheme.
Message family coverage
pain.001Customer Credit Transfer Initiation- A customer's instruction to initiate one or more credit transfers.
pacs.008FI to FI Customer Credit Transfer- A customer credit-transfer instruction between financial institutions.
pacs.002FI to FI Payment Status Report- Report the status of a payment instruction between financial institutions.
pacs.004Payment Return- Return a payment with references to the original transaction.
camt.052Bank to Customer Account Report- Report account activity and balances, commonly within the day.
camt.053Bank to Customer Statement- Provide a statement of account entries and balances.
camt.054Bank to Customer Debit/Credit Notification- Notify a customer of account debit or credit entries.
Starting payment and cash-management families, not the entire ISO catalogue. Status meanings and terminal outcomes follow the chosen community profile.
Official message definitions ↗ISO 8583 implementation scope
Connect the host.
Explain every outcome.
Design the card-message route around the processor’s host specification, from authorization to exception handling and reconciliation. Message formatting, network connectivity and the financial outcome each need their own evidence.
Build the route around the host contract.
- 01
Agree the host specification
Select the processor, ISO edition and host profile. Confirm supported transactions, response meanings, transport framing and operational responsibilities.
- 02
Define the message layout
Configure MTIs, bitmaps, field lengths, encodings, padding and private subfields. Test packing and unpacking against approved host examples, including malformed messages.
- 03
Connect and correlate
Implement authorized transport, session controls and request/response correlation. Distinguish a connected socket, an accepted message and a confirmed host decision.
- 04
Resolve uncertain outcomes
A timeout remains unknown. Handle late responses, duplicates and the host's reversal/advice procedure with original references; do not issue a fresh financial request blindly.
- 05
Reconcile and prove readiness
Match host transactions, clearing/settlement evidence and the designated ledger. Rehearse exceptions, controlled corrections and partner acceptance before enabling the route.
These are illustrative 1987-style message pairs, not promised network coverage. Other editions and private host profiles can differ. Railspan proposes the adapter and operating controls; this page packs no message and connects to no host. Network access, key provisioning, security assessment and partner certification require their own agreed implementation and acceptance.
Read the ISO 8583 message lifecycle guide →Illustrative MTI pairs / 1987-style profile
0100 / 0110Authorization request / response- Request and correlate an authorization decision; approval is not clearing or settlement.
0200 / 0210Financial request / response- Exchange a financial instruction and its host response under the agreed processing model.
0400 / 0410Reversal request / response- Reference an original transaction for reversal; confirm the host's resulting state.
0420 / 0430Reversal advice / advice response- Follow the host's advice and repeat-handling rules; not a universal alternative to a reversal request.
0800 / 0810Network-management request / response- Support agreed network-control exchanges; these messages do not establish a customer payment outcome.
Request/response and advice flows follow the selected edition and host profile. These examples do not define Visa, Mastercard or any bank’s certified interface.
Bitmap, field encoding and host controls
- MTI and bitmap
- The MTI identifies the message type; primary/secondary bitmaps indicate field presence. Neither alone proves approval, posting or settlement.
- Encoding and length
- The host defines ASCII, BCD, binary or other encodings, fixed/variable lengths and prefixes. A generic packager does not establish the partner's field contract.
- References and response codes
- Agree trace/retrieval references, original-transaction matching and response-code mappings. Retain correlation across retries and reversals without assuming a trace number is globally unique.
- Card-data and key boundaries
- Scope permitted card/token data, PIN/MAC processing and HSM/key custody with the host and security owners. Mask operational evidence; no card data or keys belong in these examples.
Reviewed ISO 8583 implementation references
Moov and jPOS provide protocol tooling to evaluate. Host adapters, key controls and partner acceptance remain scoped work; library support does not grant network access or establish certification for Railspan.
Easy to follow. Clear about responsibility.
Less searching.
A clear next step.
Design the workspace so a newly trained operator can follow a task confidently: progressive forms, explained terms, a visible owner and a reason for every blocked step. Professional judgement and authority remain part of the workflow.
- 01
Choose the task
Open an account, review an application, issue a card, investigate a payment or close the business day.
- 02
See what is missing
Required records, permissions and evidence appear beside the task. Unavailable data has a named recovery route.
- 03
Check the recommendation
Read the source, policy, calculation and alternatives in ordinary language. Inspect exceptions before continuing.
- 04
Get the right approval
The task goes to the authorized role with separation of preparation and approval where required.
- 05
Confirm the actual result
Track the provider acknowledgement and reconcile the financial effect. Keep failures and unknown outcomes visible.
One workspace, tailored to the role.
Customer service sees permitted account context. Treasury sees funding and cutoffs. Credit sees evidence and policy. Risk sees alerts and investigation history. Each role gets the information and actions it is authorized to use.
Recover without guessing.
Save a draft, explain a validation error, route an exception, show the last confirmed provider state and resume from a known checkpoint. No silent retry of a financial command.
One product, explicit responsibilities
Connect the workflow.
Keep the records clear.
A customer sees a payment. Operations sees a route, a provider state, an account entry, an invoice and a reconciliation task. Railspan brings those views together without pretending they are the same record.
Your customer and operations portals
Branded web and app experiences, operator permissions and a consistent case or transaction reference.
Governed APIs and adapters
Identity mapping, consent, versioned contracts, idempotency and events connect selected modules. Credentials remain server-side.
Payments, accounts and invoices
Assign ownership per domain. Reconcile events and financial totals before presenting a final outcome.
Exceptions, reporting and service
Surface stale provider states, ledger breaks, billing failures and settlement exposure. Connect the approved evidence to Relay.
Eight foundations / One modular offering
Choose capability.
Know its boundary.
Start with the product workflow, then select the foundation that supports it. The modules below describe the proposed platform and the software being evaluated underneath.
01 / Payment orchestration
Give payment teams a consistent way to configure provider routes and inspect payment attempts.
- Provider-connector and payment-attempt model
- Rule-based routing and configured fallback strategies
- Payment operations APIs and control-center foundation
Each connector, operation, market and edition needs validation against provider contracts. Routing does not supply acquiring, settlement access or a PCI certification for Railspan. Reconcile unknown outcomes before retrying; no authorization uplift or cost reduction is claimed.
02 / Instant-payment scheme operations
Explore participant, transfer and settlement operations for an agreed interoperable payment scheme.
- Hub participant and endpoint administration
- Participant positions, limits and transfer records
- Settlement-model and settlement-window operations
An optional scheme/operator module, not simply another PSP connector. A hub needs scheme governance, participant onboarding, regulatory authority, settlement-bank agreements and operational ownership. Installing Mojaloop does not connect Railspan to a national payment network or prove that external settlement completed.
03 / Customer, savings and lending operations
Keep customer accounts, product rules and loan or savings servicing traceable through their lifecycle.
- Customer records and configurable loan/savings products
- Applications, schedules and servicing commands
- Product accounting, journal entries and reporting APIs
Fineract is the proposed customer/account and loan/savings system of record. Wallet or stored-value fit requires separate assessment. If TigerBeetle is selected, define its distinct payment-ledger purpose and reconcile explicit mappings; never make both systems independently authoritative for the same balance. No banking license, payment rail or credit decision is provided.
04 / Payment ledger
Make the intended debit, credit and reserved amount explicit before explaining a payment balance.
- Accounts and debit/credit transfer records
- Pending transfers with post, void and expiry states
- Ledger identifiers for defined currencies or asset groups
A transaction database, not a customer core, payment processor or complete treasury service. Application identity, metadata, posting authority and external reconciliation require new work. Name one authoritative owner for each balance and map Fineract accounting, payment-ledger entries and external money movement without counting the same funds twice.
05 / Subscription billing
Make plan changes, recurring invoices and collection attempts easier for customers and finance teams to follow.
- Catalogs, subscription lifecycle and plan changes
- Invoice and billing-account operations
- Payment integration through configured plugins
Choose one invoice owner per billing domain. Kill Bill and Lago are alternatives or deliberately separated domains, not two mandatory invoice engines. Catalog, proration, tax, credits, collections, plugins and premium features need an agreed scope and acceptance examples. A payment plugin does not establish provider access.
06 / Usage metering and billing
Connect a charge to the usage events, pricing rule and invoice that explain it.
- Usage-event ingestion and billable metrics
- Usage pricing, subscriptions and invoice records
- Payment-provider integration and payment-status synchronization
Choose Lago or Kill Bill as invoice owner for each billing domain, with explicit boundaries if both are used. Usage deduplication, late events, corrections and finance reconciliation need validation. Review AGPL obligations, selected component licenses and premium/embedded rights before promising a branded deployment; no proprietary relicensing rights are assumed.
Software foundation & license
Lago · AGPL-3.0; premium entitlements require separate review
07 / Optional Bitcoin acceptance
Explore Bitcoin invoice acceptance where the business, legal model and key ownership support it.
- Bitcoin payment invoices and status handling
- Optional Lightning integration
- Greenfield APIs for a scoped commerce integration
Optional and excluded from the default compositions. This scope is Bitcoin/Lightning, not stablecoins, generic crypto acceptance, an exchange or a custody service. Define wallet/key ownership, node operations, confirmations, refunds and accounting; no fiat conversion or settlement partner is supplied.
08 / Bank API and consent access
Expose permitted account information and bank services through a governed API layer.
- Bank/account API abstraction and connector foundation
- Consent and API-entitlement controls
- Configurable views of permitted account and transaction data
Bank connectors, consent journeys, identity checks, scopes and revocation behavior require implementation and testing. Review AGPL/commercial terms and every selected component before branding or distribution. An API standard or consent model does not confer PSD2 certification, regulatory authorization or access to a bank.
Software foundation & license
Open Bank Project / OBP-API · AGPL-3.0 or a separate TESOBE commercial license
Card acceptance & network integration
From checkout
to the final ledger entry.
Cards and gateways are a complete operating journey: secure capture, authentication, authorization, capture, refunds, disputes and reconciliation. Each stage needs a defined provider and a recoverable failure path.
01
Gateway & card lifecycle
Hosted checkout or hosted fields, authorization, capture, void, refund and payment-status investigation. Connector support and acquiring agreements define the actual coverage.
02
Tokenization & stored credentials
Keep card capture with the approved provider; separate gateway tokens, vault references and network tokens. Network token services such as MDES need their own enrollment and agreements.
03
3DS & mobile acceptance
Integrate the acquirer or vendor’s supported EMV 3DS flow, with challenge, frictionless, failed and unavailable outcomes. Mobile acceptance and wallets depend on the current platform SDK and market approvals.
04
Network API security
Use the required payload encryption, request signing and OAuth/FAPI flow for each contracted API. Credentials, certificates and key rotation belong to the institution’s secure integration boundary.
05
ISO 8583 & EMV QR
Adapt the relevant host’s message specification, timeouts, reversals and reconciliation. QR encoding, card-brand identification and protocol libraries supply building blocks, not network membership.
06
Vault & operating controls
Define card-data boundaries, token lifecycle, access controls, reconciliation, fraud-provider handoffs and dispute ownership. A vault repository does not establish PCI compliance for the assembled system.
Network API security · integration references
Mastercard Client Encryption for Java
Encrypt and decrypt Mastercard API payload fields or complete payloads using configured certificates and keys.
Current use: Payload cryptography helper; requires credentials and keys issued for an enrolled Mastercard API project.
Provides encryption/decryption code, not API transport, Mastercard access, key issuance or permission to process payments. Keep private response keys inside the approved server boundary.
MIT · Source and current guidance ↗Mastercard OAuth 1.0a Signer for Java
Create OAuth 1.0a request signatures for Mastercard API integrations, including helpers for common Java HTTP clients.
Current use: Request-signing library; the README documents RSA-SHA256 as its default and RSA-PSS-SHA256 as an option.
Signs a request but does not send it, grant API access or provision credentials. Confirm the contracted API's required authentication profile before selecting a signer.
MIT · Source and current guidance ↗Mastercard OAuth 2.0 Client for Java
Client components for Mastercard API access using OAuth 2.0, FAPI 2.0 security profiles and DPoP.
Current use: Public Java client library; supports configured token handling and HTTP-client integrations.
A client library does not enroll an application or confer scopes, API eligibility or scheme access. Configure credentials, scopes, keys and token storage for the particular API contract.
Apache-2.0 · Source and current guidance ↗Mastercard Insomnia Plugin
Configure Mastercard authentication and payload crypto/signature helpers while testing requests in Insomnia.
Current use: API-development tool for Insomnia; the repository documents OAuth 1.0a and OAuth 2.0 configuration plus encryption/signature features.
Useful for request exploration, not a production gateway, credential vault, API entitlement or deployed service integration.
Apache-2.0 · Source and current guidance ↗CyberSource REST Client for Node.js
Server-side Node.js client for CyberSource REST APIs, including configured authentication and API request helpers.
Current use: Current repository README recommends JWT for new integrations and says HTTP Signature messaging is scheduled for deprecation in March 2027.
Provider-specific client only; merchant onboarding, API products, credentials, regional availability and production acceptance remain with CyberSource and the acquirer. The repository states it is proprietary licensed.
Proprietary (per repository LICENSE.txt and README) · Source and current guidance ↗Gateway & mobile acceptance · integration references
CyberSource Flex Samples for Java
Example Java applications for CyberSource Flex tokenization, including hosted Microform fields and Flex API usage in checkout.
Current use: Integration samples; the repository demonstrates a checkout flow and token handoff rather than a standalone payment processor.
A tokenization sample does not establish PCI scope reduction, assessment eligibility, certification, payment authorization or merchant acceptance. Confirm the contracted CyberSource product and current integration guide.
MIT · Source and current guidance ↗Mastercard Gateway Android SDK
Android app helper for updating a Gateway payment session with card details and presenting Gateway browser-payment flows.
Current use: Public SDK repository. Its README directs EMV 3DS integrations to the Gateway's version 2 mobile-SDK guidance; confirm the current supported package with your Gateway.
Requires a merchant-side server for authenticated Gateway operations. The public repository and sample do not certify a merchant, processor or 3DS service; region and account support must be confirmed.
Apache-2.0 · Source and current guidance ↗Mastercard Gateway iOS SDK
iOS app helper for updating a Gateway payment session and presenting Gateway browser-payment and authentication views.
Current use: Public repository README recommends Gateway SDK v1.2.1 and directs EMV 3DS integrations to the Gateway's version 2 guidance; verify current package and regional availability with your Gateway.
Requires a merchant-side server for authenticated Gateway operations. This SDK is not a general acquirer connection, processor certification or proof of EMV 3DS approval.
Apache-2.0 · Source and current guidance ↗Mastercard Gateway Test Merchant Server
Example backend for exercising Gateway mobile SDK payment sessions, authentication and 3DS callback flows during development.
Current use: Explicitly intended for testing and development as a temporary backend sample.
Do not treat it as a production merchant backend, certified processor, security design or substitute for merchant-owned authentication, transaction controls and operations.
Apache-2.0 · Source and current guidance ↗Visa Acceptance Devices iOS SDK
Swift package entry point for an iOS acceptance-device app, including Visa-distributed TapToPhone, authentication, core and UI binary modules.
Current use: Public Swift package manifest that fetches binary modules from Visa's repository; validate current device, market and merchant eligibility with Visa.
The source wrapper is not the full implementation: vendor binaries, supported hardware, enrollment and applicable acceptance approvals must be reviewed separately. Do not infer processor or device certification from a public package listing.
Apache-2.0 repository; confirm separate terms for fetched binary modules · Source and current guidance ↗Card protocol tooling · integration references
Moov ISO 8583
Go library for defining message layouts and packing, unpacking and inspecting ISO 8583 messages.
Current use: Protocol-format library; its README notes that host specifications commonly vary and supplies example specifications.
ISO 8583 formatting does not define the host connection, every network's field rules or network membership. Implement the contracted host specification, transport, security, timeouts, reversals and reconciliation separately.
Apache-2.0 · Source and current guidance ↗jPOS
Java payment-messaging framework with ISO 8583-oriented components for building transaction processing systems.
Current use: Open-source framework; the project is licensed under AGPL-3.0.
Requires implementation against the processor's message profile, transport, key handling, controls and operational agreement. AGPL-3.0 obligations need review before including it in a proprietary or hosted offering.
AGPL-3.0 · Source and current guidance ↗JReactive-8583
Kotlin/Java asynchronous ISO 8583 client and server built on Netty, with message framing, reconnect and logging options.
Current use: Open-source transport connector; the repository reports Apache License 2.0 and uses j8583 for message encoding/decoding.
A TCP connector and codec dependency do not provide a host-specific scheme specification, network access or certification. Configure framing and sensitive-field masking and review transitive dependency licenses.
Apache-2.0 (review transitive dependency terms) · Source and current guidance ↗EMV QR Code
Java encoder/parser for EMV merchant-presented and consumer-presented QR payload formats.
Current use: QR-format library with tag, duplicate, CRC and structural validation helpers.
Parsing or generating an EMV QR payload does not route, authorize or settle a payment, connect to a payment rail or establish acceptance by a scheme or acquirer.
Apache-2.0 · Source and current guidance ↗OpenEMV Utilities
EMV data parsing and terminal-oriented utilities for inspecting card data structures and supporting validation/debugging work.
Current use: The project describes itself as a partial EMVCo implementation, mostly intended for validation and debugging.
Not a complete EMV kernel, approved product, scheme certification or production acceptance stack. The library and bundled command-line tools have different copyleft obligations.
LGPL-2.1 library; emv-decode, emv-tool and emv-viewer are GPL-3.0 · Source and current guidance ↗Braintree Credit Card Type
JavaScript helper for suggesting card-brand/type from complete or partial card-number prefixes, including input-format metadata.
Current use: Small UI-oriented detection utility; its README explicitly says it is not a validation library.
A brand guess does not validate a PAN, prove issuer identity, authenticate a cardholder, detect fraud or authorize a payment. Handle any card number under the applicable card-data controls.
MIT · Source and current guidance ↗Hyperswitch Card Vault
Rust-based vault service for storing sensitive payment data, with encrypted/signed API middleware and key-hierarchy configuration.
Current use: Open-source vault implementation requiring deployment, key custody and tenant configuration.
Repository code does not certify the deployed vault or assembled payment environment to PCI DSS. Assess the chosen deployment, access controls, key ceremonies, data flows and independent compliance evidence.
Apache-2.0 · Source and current guidance ↗Interactive architecture workbench
Choose the business.
Inspect the decisions.
Select an operating model, then inspect a synthetic exception. This configures the illustration only. It does not install modules, connect a processor, create a ledger or execute a payment.
Enable JavaScript to switch the synthetic operating plan.
Selected capability set
PSP / merchant payments
- Payment orchestration
- Operational payment ledger
- One invoice owner for the chosen billing domain
Gateway agreements, card-data boundaries and reconciliation adapters remain implementation work.
Record ownership
- Account / ledger authority
- Define the operational payment ledger and reconcile it to provider and settlement records.
- Invoice authority
- Choose Kill Bill for the subscription domain or Lago for the usage domain; do not duplicate the invoice.
- Integration focus
- Connector state, idempotency, capture/refund lifecycle and verified settlement.
Synthetic exception / DEMO-RS-042
Provider outcome unknown
Trace the original request and reconcile its result before any retry or final-state claim.
Prepare the request timeline and missing-evidence checklist. A suggestion cannot authorize a payment or change a balance.
Built around your operating model
A platform with
specific jobs to do.
One product does not mean one universal deployment. These are starting configurations to validate against your products, providers and responsibilities.
PSP and merchant platform
A merchant's payment, balance and service fee are difficult to explain across separate tools.
Inspect the provider attempt, reconcile the external result to the designated payment ledger, then trace the service charge to its billing record. Choose subscription or usage billing for each domain; selecting both exposes a design choice, not a requirement to deploy both.
- Desired outcome
- Validate a traceable path from payment reference to balance and charge explanation using synthetic records.
- Operating boundary
- One invoice owner per billing domain. Keep timed-out outcomes unknown until reconciled; separately authorize refunds or payouts. No actual payment, posting or invoice is created by the composition demo.
Money-service or remittance account operations
Customer account records and provider payout evidence do not yet reconcile into a dependable operational view.
Assess the account product's fit, retrieve only permitted bank information and map an authorized provider result to its designated ledger and account records. Agree which system owns each balance before building adapters.
- Desired outcome
- Test account-to-provider references and a clear exception owner; confirm wallet/stored-value fit before committing to the core.
- Operating boundary
- Payout, remittance, FX, safeguarding and KYC/AML adapters and decisions need separate work and licensed providers. Add Mojaloop only under an agreed scheme. No money-service license or live wallet is supplied.
Bank, microfinance institution or credit union
Account servicing, loan/savings rules and permitted API access need a common operating design.
Configure one loan or savings product, review synthetic servicing and consent cases, then reconcile product accounting to a separately defined payment ledger where required. Rehearse migration and business-date close with the institution's finance team.
- Desired outcome
- Validate product behavior, access boundaries and portfolio-to-ledger agreement before a live migration decision.
- Operating boundary
- Fineract owns the agreed account/portfolio record; TigerBeetle has a distinct scoped role. No two authoritative copies of one balance. Credit, AML, adjustments and close retain institutional approval; local banking requirements remain separate acceptance work.
Payment scheme or hub operator
Participant onboarding, positions and settlement evidence need defined responsibilities across the scheme.
Model participant access and scheme rules, inspect a synthetic transfer and settlement window, then reconcile participant positions against separately confirmed settlement-bank evidence. Give any additional ledger or API layer a specific purpose.
- Desired outcome
- Identify the operator, participant, bank and control work needed for a bounded scheme pilot.
- Operating boundary
- Mojaloop requires a scheme, governance, participant integration and settlement agreements. An extra TigerBeetle ledger is not automatically required and must not duplicate Mojaloop's authoritative positions. No national-rail connection or external settlement is implied.
Useful AI patterns / Reviewed source code
Make the assistant useful.
Keep its evidence inspectable.
The reviewed examples in awesome-llm-apps offer patterns for retrieval, analysis and human handoff. Railspan’s proposed banking applications are below; the examples do not supply a production fraud model, credit model or bank connector.
01 / Typed, evidence-gated RAG
Require retrieval before answering, return a typed answer with source/chunk citations, and refuse when retrieval or quote checks fail.
Use this pattern to explain an operations question from authorized product rules, ISO 20022/8583 profiles, and institution procedures, with citations that point back to the indexed source version.
Inspected implementation & adaptation gap
Observed in the code: The agent requires its typed retrieve tool, applies a cosine-score preflight threshold, checks citations against stored source and chunk IDs, and verifies each quoted span is a substring of the indexed chunk; invalid grounding becomes a refusal. The README describes the same flow and includes deterministic tests.
Work before banking use: The example uses a session-scoped in-memory index and a heuristic similarity threshold. Citation matching does not prove a policy is current or correct. Railspan still needs tenant/source authorization, version and freshness controls, poisoned-document defenses, evaluation, access logs, and human review for consequential decisions.
02 / Corrective retrieval and query rewrite
Grade retrieved chunks for relevance, rewrite a weak query, and optionally supplement the corpus with web search before generation.
For a bank operations assistant, use retrieval grading to detect when a procedure or network profile does not answer the question, then route to an approved source owner or request clarification.
Inspected implementation & adaptation gap
Observed in the code: A LangGraph workflow retrieves from Qdrant, asks an LLM to grade each document, rewrites the question when any chunk is marked irrelevant, and calls Tavily before answer generation. The README describes uploaded PDFs/URLs, relevance grading, query transformation, and web fallback.
Work before banking use: It is a prototype, not a safe bank-source policy: web results are summarized into a document without per-result source URLs in the answer, and the generator does not enforce citations. If retrieval returns no chunks, the grading loop leaves its search flag at `No` and generation proceeds with empty context; grading errors also keep the chunk. Avoid public-web fallback for operational instructions or decisions without a separately governed source gate.
03 / Hybrid retrieval with reranking
Combine keyword and semantic retrieval, then rerank candidate chunks before answering.
Apply to exact payment references, field names, error codes and scheme terms that pure semantic search may miss, alongside natural-language descriptions in operations manuals.
Inspected implementation & adaptation gap
Observed in the code: The README specifies RAGLite hybrid search and reranking. The implementation calls `hybrid_search` for up to ten candidates, fetches the chunks, reranks them, and uses those results as RAG context; if there are no results it falls back to a general Claude answer.
Work before banking use: No answer citations or source-level confidence checks are enforced, and the empty-result path explicitly answers from general knowledge. A Railspan implementation should preserve source IDs and retrieval evidence, and fail closed or route to an operator when approved operational sources do not match.
04 / Natural-language SQL over a bounded dataset
Translate business questions into DuckDB queries and return aggregate results and visual analysis over uploaded tabular data.
Use the interaction pattern for read-only reporting over a permission-filtered operations extract, such as aging exceptions, duplicate callback counts, or SLA backlog by channel.
Inspected implementation & adaptation gap
Observed in the code: The README advertises CSV/XLSX upload and natural-language SQL. The app normalizes an uploaded CSV/XLSX file, loads it as `uploaded_data` with DuckDB tools, and gives an Agno agent DuckDB and Pandas tools to answer queries.
Work before banking use: This is a local file-analysis demo, not a live banking data connector. The agent is given general database tools without an explicit SQL allowlist, row/column authorization, query budget, approval step, immutable query log, or independent reconciliation of generated totals. Keep any Railspan adaptation read-only and narrowly scoped.
05 / Specialist financial-data research team
Route work between a web research agent and a finance-data agent, then retain interaction history in SQLite.
Adapt the specialist-tool pattern for a treasury or finance desk brief: use only approved data feeds, display source timestamps, and keep computed bank metrics separate from narrative context.
Inspected implementation & adaptation gap
Observed in the code: The README describes web research plus financial data. The implementation pairs a DuckDuckGo web agent with a Yahoo Finance tool for current stock price, analyst recommendations, company information, and news; an Agno team coordinates them and uses SQLite-backed history.
Work before banking use: Its scope is public-market research, not bank balances, payment events, lending portfolios, or regulatory reporting. The app does not enforce source citations, freshness windows, suitability checks, or approval controls; use only as an orchestration pattern, not as a finance decision engine.
06 / Support intake with rule-based human review
Convert a live support conversation into structured facts, validate missing evidence, and route exceptional cases to a human review queue in the resulting packet.
Use as a case-intake pattern for bank complaints, disputed payments, suspected account takeover, or unresolved remittance traces: collect facts, show missing evidence, identify a proposed owner, and leave the actual decision with an authorized operator.
Inspected implementation & adaptation gap
Observed in the code: The README describes intake, checklist, packet download, and human review for unknown/lapsed/mismatched policies. The implementation applies deterministic field, evidence, safety and fraud rules with routes including `needs_docs`, `policy_review`, `special_investigation`, and `emergency_escalation`; the voice instructions state that it cannot transfer the call or submit the packet.
Work before banking use: This is an insurance demo with mock policies and in-memory intake, not a bank case-management integration. Its routes are not bank-specific rules or regulated decisions. Railspan would need customer authentication, consent, institution-owned policies, access controls, durable audit and an actual authorized human queue; the assistant must not close disputes, block funds, approve credit, or execute payment actions.
Buy, compose or integrate
Compare the scope.
Then compare the cost.
A core banking quote, a gateway fee and a billing subscription buy different capabilities. Use the same modules, volumes, connectors and operating responsibilities when evaluating alternatives.
Mambu
Managed lending and deposit core for an institution that wants a vendor-operated foundation.
- Commercial basis
- Demo/expert contact; no numeric public price verified. Request a written quote for the products and volumes required.
- What to compare
- A core comparison, not an eight-module suite quote. Compare migration, integrations, support, data location and exit terms; rebranding and source rights are not assumed.
Temenos Core
Bank core modernization with institution-specific product and deployment requirements.
- Commercial basis
- Sales enquiry; no numeric public price verified. Request the exact license/SaaS, implementation and support scope.
- What to compare
- Identify contracted modules and local requirements. Broader vendor product availability does not mean payments, billing and open-banking services are included in a core quote.
Juspay Hyperswitch commercial
Payment orchestration with enterprise support or managed cloud instead of operating the community stack internally.
- Commercial basis
- Official page directs Enterprise and Cloud buyers to contact sales; no numeric quote verified. Community software is distinct from hosting and operation costs.
- What to compare
- An orchestration comparison. Edition, connectors, reconciliation add-ons, support and compliance responsibilities differ; upstream service commitments do not transfer to Railspan.
Stripe Billing
Managed recurring billing when subscription operations are the main problem to solve.
- Commercial basis
- Retrieved Netherlands page displayed pay-as-you-go at 0.7% of Billing volume, including on/off-Stripe Billing transactions and excluding one-off invoices. Recheck the buyer's market and terms.
- What to compare
- Billing-layer pricing, not core banking, a scheme, a ledger or the full Railspan scope. Confirm payment processing, tax, invoicing and usage-metering entitlements separately before comparing totals.
Sources reviewed 23 October 2026. No customer-specific vendor quote, Railspan price or cost-saving result has been established.
Implementation & operating model
Start with a complete
transaction boundary.
Choose one product, one provider path and one authoritative record. Prove the lifecycle and exceptions before adding more rails, institutions or billing models.
01
Scope
Name the institution, licensed partners, module set, record owners and expected outcomes.
02
Connect
Implement identity, adapter contracts, entitlement checks, events, keys and reconciliation.
03
Validate
Exercise unknown outcomes, duplicate delivery, reversals, ledger breaks, access denial and recovery.
04
Operate
Agree monitoring, settlement and close ownership, backups, upgrades, incident response and support.
Deployment choices
A dedicated customer environment is the initial design target. Evaluate cloud, managed hosting or on-premises against the selected modules, residency requirements and recovery evidence. Shared tenancy needs a separate isolation design.
A complete cost model
Separate implementation, migration, hosting, licenses, provider and scheme fees, certification, messaging/AI usage and ongoing operations. An open-source software license does not remove these costs.
Before you decide
Practical questions.
What does the AI decision manager do?
It is a proposed evidence and review workspace: retrieve authorized data, check freshness and agreement, apply deterministic policy checks, explain alternatives and prepare a decision for an accountable approver. The website uses fixed synthetic snapshots and scripted explanations, not live banking feeds or model inference.
Are the AI fraud and credit engines already trained and deployed?
No. The product scope includes fraud signals and rules, model integration, investigation queues, credit policy, affordability, scorecards, reason codes and monitoring. The demos illustrate a velocity/device rule and an affordability calculation. Production needs institution-approved data, evaluated models, documented policy, overrides, human authority and ongoing validation. No accuracy or lending outcome is claimed.
What does ISO 20022 implementation cover?
The proposed scope covers versioned message mapping, schema and receiving-community profile checks, controlled transmission, status and return correlation, and statement reconciliation. Initial families include pain.001, pacs.008, pacs.002, pacs.004 and camt.052/053/054. Specific routes can need more families. The correct name is ISO 20022; this demonstration does not perform XSD validation or establish network conformance.
What does ISO 8583 implementation cover?
The proposed scope covers the selected host profile, message packing, transport, correlation, duplicate handling, timeouts, reversals and reconciliation. Illustrative authorization and financial-message pairs use 1987-style MTIs; each processor defines its actual fields, encoding, response codes and certification cases. An authorization is not settlement, and an uncertain timeout is not a safe instruction to retry the financial operation.
Does Railspan have every feature for every bank?
The page maps a broad banking operating model and makes delivery gaps visible. Each institution still selects products, markets, providers and controls. Specialized services such as trade finance, securities, custody and regulatory returns need additional scope. The goal is a clear, guided experience for trained staff, with professional authority and financial controls intact.
What is Railspan?
Railspan is a proposed modular payments and banking platform offered under your brand. It combines an operating experience, integration design and selected software foundations for payments, accounts, ledgering, billing and open banking. The page demonstrates a product design; the listed systems are not already integrated into a live Railspan backend.
Do we need all eight foundations?
No. They belong to one product architecture, with modules selected for the operating model. A PSP may need orchestration and a payment ledger; a lender may need account and loan servicing; a scheme operator has a different interoperability scope. Installing every repository would add complexity without proving the workflow.
How do you avoid two systems owning the same balance or invoice?
Name the authoritative owner for each domain before integration. Fineract may own customer savings and loan accounts, while TigerBeetle owns a separately defined payment ledger. Map and reconcile transfers between those domains. Choose one invoice authority for each billing domain when using Kill Bill or Lago; do not independently bill the same usage twice.
Does this include Visa, Mastercard or a certified 3DS server?
The proposed card module integrates contracted gateway, acquiring and authentication services. Signing and encryption SDKs do not supply scheme access, issuing licenses, BIN sponsorship or processor certification. Use a currently supported vendor/acquirer 3DS service and validate the relevant mobile SDK, card-data boundary and certification requirements.
Are Bitcoin, stablecoins and foreign exchange all included?
The BTCPay foundation covers Bitcoin and Lightning merchant acceptance. It does not establish stablecoin settlement, custody, exchange or fiat off-ramp coverage. FX quotes, liquidity, safeguarding and international payout corridors require separately selected providers and operating agreements.
What is included in white-label delivery?
The proposed scope includes the branded experience, product configuration, selected adapters and operating controls. Edition entitlements, source obligations, commercial licenses, required notices and trademarks are reviewed for the selected distribution. AGPL components and vendor SDK terms cannot be treated as a single blanket permissive license.
Can AI operate the platform?
AI can explain a payment trail, retrieve authorized evidence, prepare an exception summary or suggest the next owner. Financial execution, credit decisions, sanctions decisions, key access and ledger adjustments stay behind deterministic controls and authorized approvals. Relay can support the related service conversation through a separately implemented integration.
One product. A scoped implementation.
Bring the financial workflow.
Let’s map Railspan.
Start with your institution type, products, channels, current core or gateways and the operating gap you need to close.