Why open source AML transaction monitoring fits fintechs and payment companies
This page covers self-hosted, Jube-based transaction monitoring for fintechs, payment companies, lenders and embedded finance platforms whose sponsor bank or banking partner expects monitoring over the company's own transaction flow. The short answer on platforms is Jube for transaction monitoring and yente for sanctions and PEP screening, both running inside the company's own cloud account or data center. The surrounding payment, routing and ledger stack is covered on sibling pages, so this section focuses on the monitoring layer that the sponsor bank will ask to see. The context differs from bank-scale AML in four ways that shape the design. Scoring often has to happen in the payment path, before a transfer settles, so latency and failure behavior matter as much as detection quality. Data comes from many sources at once: card or wallet activity, embedded finance partners, onboarding records and, for lenders, repayment and collections events. A single company may also run many program partners, each with its own product rules and risk appetite. And the compliance team is usually small, so the monitoring tool must produce alerts that one or two analysts can clear without a backlog. An illustrative example: a payment company with three program partners may need separate rule sets per partner while keeping one case queue and one audit trail. The practical decisions for the reader are these. Confirm with the sponsor bank which transaction types, channels and partner programs must be covered, and in what form the bank expects evidence of monitoring. Decide whether scoring runs synchronously in the authorization flow or asynchronously after posting, because that choice sets the latency budget and the failure mode. Then ask the implementation partner how Jube and yente will be sized, deployed and tested against your own volumes before any production traffic reaches them.
Which requirements shape a fintech AML build
This table maps each regulatory or contractual requirement to what it asks for, the evidence an assessor or sponsor bank will expect, and what it means for a self-hosted Jube build. Read it as a scoping checklist: many rows only apply if a specific condition in your business is true, so confirm applicability before budgeting controls.
| Requirement | What it asks for | Build meaning for a monitored payment flow |
|---|---|---|
| FTC Safeguards Rule (16 CFR 314.4) controls | Encryption of customer information in transit over external networks and at rest, MFA for anyone accessing information systems, change management procedures, and logging of authorized user activity | Encrypt Jube traffic, case data and backups, enforce MFA on analyst and admin consoles, route rule and model changes through change control, and log every analyst action on alerts and cases |
| Penetration testing and vulnerability assessments (16 CFR 314.4(d)(2)) | Where continuous monitoring is absent, annual penetration testing and vulnerability assessments at least every six months | If you do not run continuous monitoring of the scoring cluster, schedule testing twice yearly at minimum and cover the APIs that receive live transactions |
| PCI DSS scope (v4.0.1, the only active version) | Applies if card data or sensitive authentication data is stored, processed or transmitted, or if a system could affect the cardholder data environment | Confirm whether card numbers or tokens reach the scoring service. Tokenize upstream where possible to shrink scope, and confirm with your acquirer or sponsor bank who validates |
| DORA ICT contract, register and exit (EU payment institutions) | Register of all ICT contractual arrangements, contracts stating service location and data processing locations, and tested exit strategies for services supporting critical or important functions | Record the self-hosted Jube stack and any partner or hosting contracts in your register, document where data is processed, and maintain a tested plan to move monitoring to another platform |
| Swift Customer Security Controls Framework (only if connected to Swift) | 32 controls (26 mandatory, 6 advisory) assessed independently, with annual attestation in the KYC-SA application | Applies only if you connect to Swift. Map Swift-facing systems and payment message flows into the scope of the monitoring build and confirm the assessment method with Swift |
| Record preservation (17 CFR 240.17a-4), broker-dealer functions only | Preservation of certain records for not less than three years, the first two in an easily accessible place | Applies only where a broker-dealer function exists. Otherwise, confirm which retention rules your sponsor bank imposes for alert, case and transaction records |
| Sponsor bank expectations | Often set monitoring coverage, alert thresholds, model documentation, reporting and audit access in the program agreement | Obtain these expectations in writing before design. Treat any sponsor bank requirement not in the contract as unconfirmed until your compliance lead signs off |
Real-time scoring in the payment flow or batch monitoring after the fact
Synchronous scoring calls the monitoring engine inside the authorization or payout path, so the engine returns a score or decision before the payment completes. This pattern can stop a suspicious transfer before funds leave the account, which is the main reason firms choose it. It also puts the monitoring service on the critical path of every payment, so its latency and availability become payment availability. Before design starts, define the latency budget the processor will tolerate and confirm with your team how Jube behaves at your peak volume, since its latency characteristics depend on rule count, model complexity, hardware and database configuration.
- Latency budget: Agree a maximum response time with the processor and test Jube under peak load in your own environment before you commit to the pattern.
- Fail-open or fail-closed: Decide in writing what happens when the engine times out. Fail-open approves payments without a score, while fail-closed declines or holds them, and each choice has a different customer and loss impact.
- Processor integration: The processor or orchestration layer must send the transaction synchronously, accept a decision code and support holds, declines and step-up checks without breaking authorization messages.
- Ledger coupling: The ledger must reflect pending and held amounts consistently, so a held payout is not released twice if a retry arrives.
- Typologies that suit it: Account takeover, card testing, mule account first use and high-velocity payout abuse, where stopping the transaction matters more than reviewing it later.
Confirm the timeout, fallback and hold behavior with both the processor and your sponsor bank before go-live.
Asynchronous monitoring consumes transaction events from a stream or batch feed after the payment has settled or been authorized, then scores them and raises alerts for investigation. The payment path stays independent of the monitoring service, so a slow or failed scoring job does not block customers. The trade-off is that funds may already have moved when an alert fires, so recovery, reversal and customer contact become part of the operating process. This pattern usually fits better for patterns that unfold over days or weeks.
- Event stream feed: Publish every settled or posted transaction, with a stable identifier, to a durable queue so the engine can replay events after an outage.
- Data pipeline: Join transactions with customer, device, counterparty and KYC attributes in a pipeline you control, and record the timestamp at which each attribute was known.
- Alert timing: Set the target time from event to alert with your compliance team, and confirm how Jube handles late or out-of-order events in your architecture.
- Ledger reconciliation: Reconcile monitored events against the ledger daily so that scored events match booked balances and no transaction is missed.
- Typologies that suit it: Structuring across accounts, layering through chains of transfers, trade-based or invoice patterns and network analysis, where the signal emerges from history rather than a single payment.
Ask the implementation partner to show how replay, backfill and dead-letter handling work before you rely on them for detection coverage.
Most fintechs and payment companies do not choose one pattern for every product. A card or instant payout product with fast fund movement often needs a synchronous check for a narrow set of high-risk signals, while the broader monitoring program runs asynchronously over the full transaction history. Both paths should share rules, features and case records, so an alert from one path is visible to investigators working the other. The decision depends on how quickly funds can be recovered, how much latency the processor will accept and how many customers a false hold would affect.
- Hybrid design: Use a light synchronous check for the few signals that must act before settlement, and send everything to the asynchronous engine for deeper scoring.
- Shared feature definitions: Keep rule logic and features consistent across both paths so the same customer is not judged differently depending on timing.
- Recovery economics: Estimate, with finance and risk, how often funds can be recalled after settlement for each product line before choosing where to place controls.
- Customer experience: Holds and step-up checks add friction, so test their volume against the false positive rate you can support with your analyst staffing.
- Governance: Document which rules run on which path, who approved each fail-open setting and how changes are versioned for examiners.
Before you commit, ask your sponsor bank and processor which path they expect for each product and whether they require a documented fallback.
Which open-source platforms fit a payment company's AML stack
Five open-source platforms make up or feed a payment company's monitoring chain. Jube and yente make the monitoring and screening decisions, while Hyperswitch, Kill Bill and Apache Fineract supply the payment, billing and lending records those decisions depend on. Confirm event fields, latency and data ownership for each link before you fix the design.
Jube for real-time scoring
Jube is the scoring and case engine that runs in the payment flow. It applies rules and models to each transaction before authorization or settlement, so the design depends on latency at your peak volume. Confirm which rule and model types it supports, how case records and audit logs are stored, how rules are versioned and tested before release, and whether integration uses synchronous API calls, event streams or batch files.
yente for sanctions and PEP screening
yente screens customer and counterparty names against sanctions and PEP lists built from OpenSanctions data. In the chain it runs at onboarding and on payment parties, and its matches should land in the same case queue as transaction alerts. Confirm the data license your use requires, especially for internal commercial use, and agree match thresholds and list refresh cadence with your compliance team before go-live.
Hyperswitch for payment event flow
Hyperswitch is the orchestration layer where card and account payment events originate. Its Apache-2.0 license and self-hosted option let you keep routing and event data inside your own network. The latest tagged release, v1.128.0, was published October 16, 2026. Confirm which processors, fraud and vault providers you connect, which event fields reach Jube, and whether your sponsor bank accepts that data path. Check PCI DSS scope before any cardholder data passes through it.
Kill Bill for recurring billing events
Kill Bill manages subscription plans, invoices, recurring charges and payment retries for lenders and platforms that bill on a schedule. Its invoice and payment records show why money moved on a repeating basis, which helps monitoring spot sudden changes in recurring payers. Confirm which billing events are exported to Jube, how account and invoice identifiers map to your customer records, and where payment method data is stored. The Apache-2.0 release killbill-0.24.22 was published September 29, 2026.
Apache Fineract for lending records
Apache Fineract is an Apache-2.0 core banking platform that holds loan and savings account records. For lender monitoring, it provides the disbursements and repayments that transaction alerts should be checked against. Confirm whether these events reach your monitoring system in near real time or in batches, which team owns account status changes, and how Fineract identifiers link to your customer and case records. Version 1.15.0 was published July 14, 2026.
How a small compliance team handles alerts and cases
A small team cannot work every alert the same way, so triage must decide which alerts reach a human first and which close under documented rules. Tier alerts by typology first and by score second, so that rapid pass-through of funds on a newly onboarded account, structuring around a threshold, and sudden changes in counterparties each land in a queue owned by someone who knows that pattern. In embedded finance, one end customer may appear under several partner programs or sub-ledgers and generate parallel alerts for the same activity. Merge those under a single customer-level case key before assignment. Confirm with your sponsor bank and program managers which entity owns the customer record and whether they expect to see partner-level alerts.
Every closure needs a disposition reason that someone could defend to an examiner. Require analysts to choose from a controlled list, such as explained by known business activity, false positive traced to a documented rule issue, or insufficient evidence after review, and to write a short narrative naming the transactions and data they checked. Route anything that suggests suspicious activity to a second reviewer who makes the escalation decision, and time-stamp each decision. Confirm in writing with your counsel and sponsor bank who makes the suspicious activity filing decision and how the team tracks the deadlines that run from detection, because those deadlines set how fast the queue must move.
The case file should let a reviewer rebuild the decision without asking the analyst. Include the alert ID, the rule or model name and version that fired, the input data snapshot, the customer and linked party profile, the transaction history used, analyst notes, the disposition and its reason, the reviewer sign-off, and any evidence attachments. Rule and model changes need the same discipline: a change request stating the business reason, backtest results against recent alert history, an approver who did not write the change, the effective date, and a stored version so that any past alert can be explained against the logic that was live at the time. Ask your implementation partner how Jube configuration changes are versioned, reviewed and rolled back in your environment before the first production rule goes live.
How the Jube cluster scales with transaction volume
A Jube deployment in the payment flow scales as a set of parts, each with its own bottleneck. The cards below cover the components that matter most when you size the cluster, and each one lists what drives its growth and what to measure in a load test before you commit to a size.
Stateless scoring nodes behind a load balancer
Scoring nodes evaluate each transaction against rules and models and hold no session state, so you add nodes to add throughput. The main drivers are transactions per second at peak, the number of rules and models evaluated per event, and the payload size sent by the payment flow. Load test at your real peak, including authorization retries and burst patterns from card and instant payment traffic, and measure p99 latency at each node count. Confirm how Jube's API handles connection pooling and timeouts with your load balancer before you set limits.
Data store and feature history
Rules that look at velocity, counts and aggregates depend on a store of past transactions and computed features. Storage grows with event volume and the retention period your policy sets, while query cost grows with the size of the lookback windows your typologies use. Measure query latency for the longest window you run in production, not the average, and test the cost of rebuilding aggregates after an outage. Ask your team to document the retention period for each data type before you size storage.
Message bus feeding events
A message bus decouples the payment flow from downstream work such as case creation, enrichment and reporting. It absorbs bursts so the scoring path is not blocked by slower consumers. Drivers are message size, partition count and consumer lag tolerance. Measure consumer lag during a peak replay and confirm the time to drain the backlog after a consumer outage, because a backlog that clears slowly can delay alerts past the point where a payment can still be held.
Screening service with cached list data
Sanctions and PEP screening runs against a local index built from list data, so each lookup does not call an external service. Memory and CPU scale with the size of the loaded datasets and the matching thresholds you configure, and refresh jobs add load on a schedule. Measure match latency with the full dataset loaded, the time to load a new list version, and the behavior when a refresh fails. Confirm the list licensing terms before you plan how many instances hold a copy.
High availability across zones or sites
High availability means the scoring path keeps working when a node, zone or site fails, and the choice has cost and data consequences. Active-active designs need replicated state and clear rules for which site decides when they disagree. Test failover with live-like traffic, record the recovery time and any transactions that were scored twice or not at all, and document the fallback decision for the payment flow when scoring is unavailable.
Observability stack
Metrics, logs and traces show whether the cluster is meeting its latency targets before analysts see a backlog. The stack itself adds load and storage, and logs can contain personal data that must be protected and retained under your policy. Measure the overhead of tracing at peak, set alerts on scoring latency, consumer lag and list refresh age, and confirm that the logs needed for examiner reviews are kept for the full retention period.
How a monitoring rollout runs from requirements to sponsor sign-off
The sequence turns a fintech's payment flows and risk appetite into a monitoring system that has been tested on history, tuned under change control, and reviewed by the sponsor bank before it scores live payments.
Define requirements and the typology register
The compliance lead, the head of payments and DeployOpen agree on which products, payment rails, geographies and customer segments are in scope, the latency each payment flow can tolerate, and the typologies the program must detect, such as structuring, rapid pass-through and first-party fraud. The output is a typology register that maps each typology to a data source, a rule or model candidate, an owner and the alert volume the team can work. The step closes when the compliance lead signs the register and the scope is recorded in the statement of work.
Map data sources and event contracts
Engineers document every event the scoring service needs, including payment initiation, authorization, onboarding, device and account changes, and returns, and define the field names, types, timestamps, currency handling and identifiers for each one. Each event gets a written contract that names the producer, the consumer, the expected fields and what happens when a field is missing. The output is a data map and signed event contracts. The step closes when a test payload from each producer passes schema validation in a non-production environment.
Run shadow scoring on historical payments
Jube scores a historical window of payments and events without affecting any live decision, so the team can see which transactions would have alerted under the proposed rules and models. Analysts review a sample of alerts and confirmed prior cases to measure how often the output matched known outcomes. The output is a shadow-run report with alert volumes, hit rates by typology and the cases the system missed. The step closes when the report is reviewed against the typology register and gaps are logged as tuning items.
Tune rules and models under change control
The team adjusts thresholds, rule logic and model features to reduce noise while keeping coverage of the typologies in the register. Every change is recorded with the reason, the author, the reviewer, the data window used and the before and after results, and model changes are tied to a versioned model artifact. The output is a change log and a validation record for each rule set and model version. The step closes when the second reviewer approves the final version and the validation record is stored with the release.
Configure case workflow and record retention
Engineers and compliance staff set up alert queues, priority logic, escalation paths, case notes, evidence attachments and four-eyes approval for closing or filing decisions. Retention periods are set from the institution's legal and sponsor bank requirements, and access to cases is limited by role and logged. The output is a tested case workflow, a retention schedule and an access matrix. The step closes when a test case moves from alert to closure with a complete audit trail, and the team confirms the retention settings with counsel.
Assemble the sponsor bank review pack
DeployOpen compiles the documents the sponsor bank will ask for: system architecture, data flows, the typology register, the validation record, the change log, shadow-run results, the case workflow description, access controls and the operating procedures for alert handling. The compliance lead reviews the pack for accuracy, and open items are listed with owners. The output is a versioned review pack. Sponsor bank expectations vary, so the team should confirm the exact document list in writing before work begins.
Go live in a controlled phase
The system starts scoring a defined share of live traffic or a defined set of products, with alerts routed to the trained team and daily review of volumes, latency and queue age by the compliance lead. Thresholds and rules stay frozen unless a documented change passes the same review as before. The output is a go-live record with monitoring dashboards and an incident log. The step closes when the sponsor bank confirms the review and the controlled phase exits to full scope under the agreed criteria.
Run post-launch tuning on a fixed cadence
After full launch, the team reviews alert outcomes, false positive trends and new typologies at a scheduled interval, and applies changes through the same change log and validation process. Scaling decisions for the cluster are tracked against latency and throughput measurements. The output is a recurring tuning report and an updated validation record for each change. The step is complete when each review produces either a documented change or a documented decision to keep the current configuration.
Evidence a sponsor bank or examiner will ask for
This table lists the records a sponsor bank, examiner or independent assessor is likely to request from a self-hosted AML monitoring stack, and the platform component that generates each one. Read it as a preparation list: DeployOpen prepares the evidence, but auditors, sponsor banks and examiners form and issue any opinion on it.
| Evidence item | What the reviewer checks | Component that produces it |
|---|---|---|
| Rule and model inventory with versions | Every live scoring rule and model, its owner, version, effective date and typology it addresses | Jube rule and model configuration, exported under version control |
| Change management records | Who approved each rule or threshold change, the test results and the rollback path | Git history, pull request approvals and change tickets in the ticketing system |
| MFA and access logs | Named users with access to the case manager and configuration, and proof that MFA is enforced | Identity provider logs, Jube access logs and privileged session records |
| Encryption configuration | Customer data encrypted in transit and at rest, with key ownership and rotation documented | Database and object storage encryption settings, TLS configuration and key management records |
| Penetration test and vulnerability assessment reports | Independent test results, remediation status and retest evidence for the monitoring environment | Third-party test reports, scanner output and remediation tickets, reviewed against the FTC Safeguards Rule testing cadence where it applies |
| Case files and alert dispositions | Each alert's evidence, analyst decision, approval, and any suspicious activity report decision with timestamps | Jube case manager, attached transaction data and analyst notes exported with an audit trail |
| Screening audit trails | Which list version screened which name or payment, match scores, and how each potential match was resolved | yente query logs, dataset version records and reviewer decisions stored with the payment reference |
| DORA register entries and exit plans | Where the entity is in scope, a register of ICT contracts, data locations and a tested exit plan for the monitoring service | Contract register, subcontractor records and the documented exit and transition plan maintained by the firm |
What do fintechs ask before hiring an AML implementation partner
What drives the cost of an AML transaction monitoring implementation?
Scope drives most of the cost: the number of payment flows to monitor, the number of typologies and rules to build, how many data sources feed the engine, and how many integrations reach the case tool, core ledger and payment processors. The software itself is open source, so you pay for the partner's planning, build, testing, documentation and handover, plus the infrastructure you run in your own cloud or data center. Ask for a quote that splits one-time work (design, build, validation, documentation, training) from recurring work (hosting, watchlist data licensing, tuning and support). Each line should name who is paid for what and which deliverables it produces.
How long does a fixed-scope monitoring build take?
The duration depends on scope, and the partner should set it in the written statement of work before work starts. The main variables are the number of transaction types in real-time scoring, whether scoring sits inline in the payment flow or runs after settlement, how many case-handling workflows the compliance team needs, and how much historical data must be backtested before go-live. Ask the partner to break the timeline into phases with named deliverables and acceptance criteria, and to state which dependencies, such as sponsor bank sign-off or data access, sit on your side. DeployOpen does not publish fixed durations, so the quote is the reference point.
What must our team provide before an AML build starts?
The partner cannot tune detection without your inputs. Expect to provide transaction data samples and a data dictionary, your product map (payment types, geographies, customer segments, and any embedded partner programs), and the typologies your risk assessment already identifies. You also need named owners for the rule set, the case workflow and the sign-off process, plus any written requirements from your sponsor bank, such as alert thresholds, reporting formats or retention expectations. Gaps here tend to appear as rework during validation, so ask the partner to publish a data request list at the start of the engagement.
Can a small internal compliance and engineering team run Jube alone?
A small team can run a self-hosted monitoring stack, but the work is wider than installing software. Someone must operate the cluster, apply upgrades, manage keys and access, and keep logs and backups working. Someone else must own rules, model documentation and alert triage, and that person needs to explain tuning decisions to examiners. Before deciding, list who owns each function, how many hours per week that ownership consumes, and who covers absences. Many teams use a partner for the build and validation, then decide whether to keep operations in house or buy a support retainer.
How do sponsor bank reviews change the scope of an AML build?
Sponsor banks typically review the fintech's monitoring program as part of their own oversight, so their expectations can add scope. Common additions include documented typologies, evidence of rule validation, alert and case metrics, change control records for rule updates, and access to reports on request. Ask your sponsor bank for its written requirements before scoping, and ask the partner how it will map each requirement to a deliverable. The sponsor bank's expectations do not come from DeployOpen or from open source software, so confirm them directly with the bank and record the answers in the statement of work.
What does an ongoing support retainer cover after go-live?
Retainers are available for ongoing support, upgrades and continuous testing, and the exact coverage is set in the agreement. Typical items include platform patching and version upgrades, monitoring and backup checks, rule and model tuning cycles, adjustments when sponsor bank or regulatory expectations change, and periodic security testing of the monitoring environment. Ask the partner to list response windows, which are the SLAs and must appear in writing, and what happens to work outside the retainer, such as new integrations or new products. A retainer should also cover documentation updates so the evidence stays current.
Which records and evidence should a monitoring build produce?
A monitoring build should leave behind evidence an examiner or sponsor bank can review without asking the engineers to explain the system. Useful outputs include a data flow diagram, rule and model documentation with version history, validation results from backtesting, access and change logs, alert and case records with timestamps, and retention settings for transaction and case data. The retention period depends on the regime that applies to your business, so confirm the requirement with your compliance counsel before setting retention in the platform. Ask the partner to show how each record is produced and where it is stored.
What should we ask a partner about security and hosting before signing?
Ask where the platform will run, who has administrative access, how secrets and encryption keys are managed, and how logs are retained and protected. For payment data, ask whether the monitoring cluster falls inside your PCI DSS scope, which depends on whether it stores, processes or transmits cardholder data or could affect the security of that environment. Ask how the partner will support any penetration testing and vulnerability assessment your regulators or sponsor bank expect. Get written answers for each point and make them part of the statement of work.
What to ask a partner before committing to a self-hosted AML build
Start with the questions that decide whether a small team can run this system after go-live. Ask any partner how they tune real-time rules and models for your typologies, and require the answer in writing: who sets thresholds, how a new scenario is tested against historical transactions before it touches the payment flow, and how the team measures false positives per rule. A partner who cannot show a replay of past payments through a candidate rule has not run this work before. Ask how they handle false positive reduction without quietly raising thresholds to shrink the queue, because a sponsor bank will ask why alerts fell and which typologies lost coverage.
Next, ask for the evidence pack your sponsor bank will expect. Request a sample of what the partner would hand over: rule and model documentation, the change log for each Jube rule set, backtesting results, alert and case volumes by typology, and the audit trail that ties a decision to the person who approved it. Ask who owns each artifact after handover. Then cover data licensing for screening lists: confirm which OpenSanctions data products your use requires, who signs the license, and who pays when a list changes. Ask the same of any hosted data feed the partner proposes, since a license gap found during an examination is expensive to fix.
Finally, ask about change control, scaling and support, since these carry most of the long-term cost. Require a written change procedure for rules and models with approval roles, a test environment, and a rollback path. Ask for the high availability design and the load test results at your projected peak transaction rate, not a generic capacity claim. Confirm the support model: response windows, who is on call for payment-hours incidents, and whether upgrades to the monitoring stack and its dependencies are included in a retainer or quoted separately. Ask for these answers in the proposal, not in a sales call, so your team can compare partners on the same terms.
