BNDRY for Payments

If you run compliance at a payments company or fintech, your customers are the merchants you onboard — businesses whose ownership you need to understand, whose activity can often cross borders and a variety of different payment methods, and whose own customers you're exposed to from a risk perspective. This guide explains how BNDRY maps onto the compliance work a payments business actually does: how to set BNDRY up, and how the day-to-day processes — onboarding, KYB, identity verification, due diligence, investigations, and information requests — work for a payments provider.

It assumes you already know your own AML/CTF program. Where a process has a standard shape in BNDRY, this guide points you to the tutorial that walks it step by step, and focuses instead on what's specific to payments.

Risk factors in payments and fintech

The work at a payments business is shaped by both the financial-crime risk you carry and what triggers the due diligence you do around it. Four things make it distinctive:

• You onboard businesses, not just people — a merchant is a company, and the risk often sits in who stands behind it. Verifying a business means establishing its ownership and control structure, and working down through the ownership structure to the ultimate beneficial owner (UBO). That structure can be deliberately opaque — shell companies, layered holdings, ownership with no clear commercial rationale — and seeing through it is core to the work.
• Cross-border and corridor exposure — payments move across jurisdictions, so a merchant's risk includes the countries, regions, and currencies its money flows to and from. Exposure to sanctioned, prohibited, or high-risk jurisdictions is a primary risk factor, and an AML program prescribes how you escalate your risk management based on the activity that your merchant customers are performing.
• You inherit your merchants' risk — a payments provider is exposed not only to its merchants but to its merchants' customers. Part of assessing a merchant is judging whether they run adequate due diligence, monitoring, and fraud controls of their own, because weaknesses there become your exposure.

• Investigation and due diligence triggers — investigation triggers are typically transaction-monitoring signals that you then work in BNDRY:

  • payments to or from sanctioned, prohibited, or high-risk merchants, individuals, or countries
  • significant deviations in trend — a spike in a particular currency, or in payments to or from a particular country, especially a high-risk one
  • sharp changes in the volume or value of a merchant's payments

  Enhanced due diligence is often performed as a result of these behavioural deviations, or when a merchant has been identified as high-risk. Ongoing due diligence keeps your risk profiling of a merchant current, based on their present ownership and control, their customer base, and their activity.

How BNDRY fits the work

Each part of the work has a home in BNDRY. This is the shape of it at a glance; the rest of the guide works through the payments-specific parts in more detail.

Setting up BNDRY for your business

A little configuration up front makes everything that follows fit how a payments business works.

• Hold merchants as Company entities — and the individuals behind them, the UBOs and directors, as Individual entities. Each profile is the durable record that verification, screening, reviews, and any investigations attach to. See how entities work.
• Add custom fields for the depth payments demands — the amount of information a payments business tracks against a merchant is significant. Typical fields cover platform and provider IDs, merchant category (MCC) codes, the pay-in and pay-out solutions a merchant uses, cross-border operations, regulatory registrations, and a status and risk rating per processor or banking partner. See Designing custom fields.
• Configure risk levels to match your model — your OCDD cycle is driven by risk level, and a rules-based risk rating can calculate a merchant's rating from the data points you hold. See Configuring risk levels.
• Build the forms your processes need — a merchant onboarding form, a risk-assessment form, an ECDD form for source of funds, an information-request form. See Designing form templates.

Key processes for a payments business

The mechanics of each process are covered in their own tutorials. What follows is what each one looks like for a payments provider.

Merchant onboarding

Onboarding is where most of the work concentrates, and it starts with a form. You configure onboarding forms in BNDRY that reflect exactly the information you collect — with specific questionnaires for the specific payment services you provide. A form can ask for expected payment volumes, the payment types involved (cross-border, cards, NPP, and so on), the business model and customer profile, and everything else you need to assess a merchant for risk. Because you design the form, it captures precisely what your onboarding process requires.

The form lives in BNDRY, but the merchant is the one who completes it. Typically an accounts or sales team is already working with a prospective merchant, and as that progresses the merchant needs to be onboarded. You do this by sharing a Workspace with them: the prospective merchant is invited to complete the onboarding form through BNDRY's secure portal, and everything they submit lands back against their record. See Requesting information from a third party for how Workspace sharing and the portal work.

KYB and beneficial ownership

BNDRY connects to KYB data sources so you can verify a business's ownership and directorship as part of onboarding. From there you can drill down through the ownership structure — unwrapping layers of holdings to identify the ultimate beneficial owner behind the merchant. This is the part of onboarding where a complex or opaque structure shows itself, and where seeing through to the real owners matters most.

Identity verification

Alongside verifying the business, you can instigate identity verification on the individuals associated with a merchant. This is typically required when you need to individually verify the UBOs and directors of a merchant being onboarded — confirming the people behind the business are who they say they are.

When you instigate a verification, the individual is given a guided experience on their own device: they provide their identity document and complete a biometric or liveness check to confirm they're a real person and that they match the document. The result of the verification is returned to BNDRY and stored against their record, so the outcome sits alongside everything else you hold on the merchant and the people behind it.

Tracking merchants and ongoing due diligence (OCDD)

Once onboarded, every merchant is a tracked entity, and the job is making sure the appropriate due diligence is being performed against each one over time — along with any investigations or reports that apply. OCDD reviews are periodic and risk-level-based: a higher-risk merchant is reviewed more often than a lower-risk one, on a cycle you define, and a change in a merchant's risk level is itself a prompt. The risk levels you configured are what drive that cycle. The review process follows the standard shape — see Conducting an Ongoing Customer Due Diligence review in BNDRY.

Running an investigation

In payments, an investigation is typically prompted by a transaction-monitoring signal — payments to or from sanctioned or high-risk merchants, individuals, or countries, or a significant deviation in trend such as a spike in a particular currency or corridor. Once a signal is flagged, you work the investigation in BNDRY: a staff member records what was flagged and opens an investigation Workspace against the merchant.

Because you design the investigation form, it can capture the evidence and research your process gathers. Many AML programs also require ECDD on any entity that's been investigated, so you can add an ECDD form into the same investigation Workspace, letting the one Workspace encapsulate the whole process from the initial trigger through to the enhanced due diligence and the determination. The investigation process itself — capturing the event, escalating for review, reaching a determination — is covered in Running an investigation in BNDRY.

Enhanced customer due diligence (ECDD)

Enhanced customer due diligence is the deeper level of scrutiny you apply when a merchant presents a higher risk than standard due diligence is designed for. AML programs typically require ECDD on any entity carrying a high-risk rating, and on any entity that's been the subject of an investigation or an SMR. ECDD is often performed as a result of the behavioural deviations a merchant's activity throws up, or once a merchant has been identified as high-risk through onboarding or review.

What earns a high-risk rating is unique to each program, but in payments it's commonly a product of the merchant's regulated status, its geographic and corridor exposure, the PEP exposure of its directors or owners, the transparency of its ownership, its source of funds, and whether its own customer due diligence is adequate. In BNDRY you can codify these parameters as a rules-based risk rating, so the rating is calculated automatically wherever the underlying data points are available in the platform.

Where standard due diligence confirms who a merchant is, ECDD sets out to understand them well enough to be confident the relationship is legitimate. In a payments context that usually means going further on several fronts:

• Source of funds, and source of wealth where it applies — establishing where the money flowing through the merchant comes from, and, for the individuals behind it such as UBOs and directors, how their wealth was accumulated where that warrants scrutiny.
• Beneficial ownership in depth — working through complex or layered ownership to confirm the ultimate beneficial owners, and understanding why the structure is shaped the way it is.
• The merchant's own customers and controls — looking past the merchant to the customers it serves, and judging whether its own due diligence, monitoring, and fraud controls are adequate, since its exposure becomes yours.
• Adverse media and reputation — checking for negative media or other public red flags against the business and the people behind it.
• Closer ongoing scrutiny — applying tighter review cycles and watching the merchant's activity more closely once it's in a higher-risk band.

Each of these is gathered, recorded, and resolved in BNDRY against the merchant's entity, so the enhanced work — and the reasoning behind your conclusions — sits on the one record. See Configuring risk levels to set up your risk rating, and Conducting Enhanced Customer Due Diligence in BNDRY for the process itself.

Requesting information with payment RFIs

A payment request for information (RFI) is a structured way to ask a merchant for missing, unclear, or additional information. RFIs run across the whole merchant lifecycle, and they're a routine, high-volume part of payments — a meaningful share of payments end up needing one. Common situations include:

• Filling gaps in onboarding data — chasing missing KYB documents, beneficial ownership details, or resolving a mismatch between a registered name, trading name, or tax ID.
• Underwriting and financial risk — requesting processing history, prior chargeback rates, or financial statements to assess a merchant's stability.
• Verifying the business model — clarifying what a merchant actually sells and how it operates, or asking for proof where the activity looks high-risk.
• Investigating a transaction — asking for the invoices, contracts, or context behind a payment that a monitoring signal has flagged.

BNDRY replaces emails with a structured request. You configure an RFI form for exactly what you need, and share it through the secure portal; the response comes back structured and lands against the relevant record. See Requesting information from a third party for how Workspace sharing and the portal work.

Managing chargeback cases

Chargebacks are a process every card-processing business has to manage, and they follow the same Workspace-as-case pattern as an investigation — just pointed at a dispute rather than a risk concern. You can configure a chargeback form that captures the notification details (the merchant, the transaction, the card brand and amount, the case reference, the reason, and the response deadline), then share the Workspace with the merchant through the portal so they can respond.

From there the merchant chooses whether to accept or dispute the chargeback and uploads any supporting evidence — an invoice, proof of delivery, cardholder communication, or the like — which lands back against the case. Because the whole exchange lives in one Workspace linked to the merchant, each dispute becomes part of that merchant's history, so you can see their chargeback record alongside everything else you hold on them.

Other processes you can track in BNDRY

Beyond the core onboarding and due diligence work, a payments business can use BNDRY to keep a record of other processes against a merchant's entity, so they build into the same history:

• Risk rating changes and decision records — keep a record of when and why a merchant's risk rating changed, and the reasoning behind the decision, so the rating is always backed by a documented rationale.
• Periodic reviews of high-risk or high-volume merchants — track scheduled reviews of the merchants that warrant the closest attention, capturing what was looked at and what was decided each time.
• Meetings and correspondence with a merchant — log conversations, meetings, and significant correspondence, so context gathered along the way forms part of the record.
• Employee due diligence — record the due diligence performed on your staff, including employee training completed and police checks run, building an auditable history of who was checked and trained and when.
• Offboarding and continuation decisions — document a decision to offboard a merchant, or to continue providing a designated service, together with the reasoning that supported it.

Related articles

• Conducting an Ongoing Customer Due Diligence review in BNDRY
• Conducting Enhanced Customer Due Diligence in BNDRY
• Screening
• Configuring risk levels
• Designing custom fields
• Designing form templates