# RevCent BIN Profiles Overview for MCP This document gives an MCP-oriented overview of BIN Profiles: why they exist, what they are used for, and how they can support advanced ecommerce payment strategies. This is an overview document, not a detailed operation guide. Source: - RevCent API/MCP schema for `CreateBinProfile` and `EditBinProfile` --- ## What Is a BIN Profile? A BIN Profile is a reusable list of credit card BINs. A BIN is the first 6 digits of a credit card number. Example: ```text 411111 ``` If a card number starts with `411111`, then it matches BIN `411111`. A BIN Profile groups one or more BINs under a named profile so they can be referenced, reviewed, reported on, or used in advanced workflows. Simple concept: ```text BIN Profile = named list of 6-digit card BINs ``` --- ## Why BIN Profiles Exist BIN Profiles exist because ecommerce businesses sometimes need to recognize or group specific card BINs. A business may know that certain BINs: - Perform better with a specific gateway. - Perform worse with a specific gateway. - Have higher decline rates. - Have higher fraud or chargeback risk. - Belong to a specific card category or issuer pattern known to the business. - Need special review. - Need special reporting. - Should be included in an advanced payment-routing strategy. Instead of repeatedly configuring the same BIN list in multiple places, the business can create a BIN Profile once and reference it when needed. --- ## What BIN Profiles Do BIN Profiles help organize BIN lists. They can be useful for: - Storing user-provided BIN groups. - Keeping BIN lists named and documented. - Supporting payment-related reporting. - Supporting payment review workflows. - Supporting advanced Payment Profile filtering. - Supporting advanced Payment Profile routing. - Supporting advanced Payment Profile blocking, when explicitly intended. Important: ```text A BIN Profile does not process, route, or block payments by itself. ``` It is a reusable list. The behavior comes from whatever workflow uses the BIN Profile. --- ## What BIN Profiles Do Not Do by Themselves Creating a BIN Profile does not automatically: - Route payments. - Block cards. - Retry payments. - Abort payment flows. - Change gateway selection. - Change checkout behavior. - Affect credit card processing. - Add BIN filtering to an existing Payment Profile. A BIN Profile becomes operationally meaningful only when it is referenced elsewhere, such as inside a Payment Profile. --- # Why Ecommerce Businesses May Use BIN Profiles ## Reporting and Analysis A business may want to group payments by known BIN sets to understand trends. Examples: - Are certain BINs declining more often? - Do certain BINs have higher refund rates? - Do certain BINs have higher chargeback rates? - Do certain BINs perform better through one gateway than another? - Are certain BINs associated with a specific campaign, region, or payment behavior? A BIN Profile can provide a reusable named grouping for analysis. --- ## Operational Review A business may use BIN Profiles as watchlists or review lists. Examples: ```text High Decline BINs Chargeback Review BINs Gateway Review BINs International Review BINs ``` These lists can help organize known patterns without immediately changing payment behavior. --- ## Payment Strategy Organization BIN Profiles can support payment strategy planning. For example, a business may discover that a known list of BINs should eventually route differently, but may first create a BIN Profile to document and review the list before using it inside a Payment Profile. --- # Advanced Use: Payment Profile Filtering and Routing An advanced use of BIN Profiles is inside Payment Profiles. Payment Profiles are payment-routing flows. A Payment Profile can use a BIN Profile to determine whether a card BIN matches a known BIN list. This is usually done with a BIN filter inside the Payment Profile. Conceptually: ```text Payment starts ↓ Check whether card BIN matches BIN Profile ↓ If match, follow one path If no match, follow another path ``` This is an advanced capability. MCP should only recommend or build BIN-based Payment Profile filtering/routing when the user has advanced payment needs and can clearly explain the intended behavior. --- ## Advanced Routing Use Case A business might use a BIN Profile to route matching BINs to a specific gateway group. Example: ```text If card BIN matches the Preferred BIN Profile: route to Preferred Gateway Group If card BIN does not match: route to Default Gateway Group ``` Possible reasons: - Matching BINs approve better on a certain gateway group. - Matching BINs should stay within a specific business/corp gateway group. - Matching BINs need a fallback payment path. - Matching BINs are part of a known payment strategy. Important: Gateway groups should generally be preferred over individual gateways for routing because they help organize gateways across businesses, corporations, brands, stores, currencies, and risk strategies. --- ## Advanced Blocking Use Case A business might use a BIN Profile to block or abort payment processing for matching BINs. Example: ```text If card BIN matches the Blocked BIN Profile: abort the payment flow If card BIN does not match: continue normal processing ``` This is high-impact. Blocking should only be used when the user explicitly confirms that matching BINs should not be processed. MCP should not assume that a BIN Profile is meant for blocking. --- ## Advanced Risk or Review Use Case A business may use a BIN Profile to identify cards that need special handling. Examples: - Route matching BINs to a more conservative gateway group. - Insert metadata when a matching BIN is used. - Send matching BINs through a Function for external review. - Route matching BINs away from a gateway group that performs poorly for them. These are advanced workflows and should be used only when the business has a clear reason. --- # BIN-Based Payment Logic Should Be Used Carefully BIN-based payment filtering/routing can directly affect credit card processing. Incorrect use may cause: - Valid cards to be blocked. - Payments to route to the wrong gateway group. - Cards to avoid a gateway that would have approved them. - Cards to route across the wrong business/corp boundary. - Checkout behavior to change unexpectedly. - Subscription or trial payment behavior to change unexpectedly. - Higher declines or payment failures. For this reason, BIN Profiles should not be connected to Payment Profile logic unless the user has advanced payment needs and has clearly defined the intended routing or blocking behavior. --- # MCP Guidance When a user asks about BIN Profiles, MCP should first treat them as reusable BIN lists. MCP should ask: ```text Do you only want to create/store this BIN list, or do you want to use it in an advanced Payment Profile flow? ``` If the user only wants to create the BIN Profile, MCP should not introduce routing or blocking. If the user wants to use the BIN Profile inside a Payment Profile, MCP should clarify: - What should happen when the BIN matches? - What should happen when the BIN does not match? - Is the goal routing, blocking, review, or reporting? - Which gateway group should be used? - Should matching BINs be blocked? - Does the user understand this can affect credit card processing? - Should the related Payment Profile be created or edited disabled first? --- # Important Data Safety Rules BIN Profiles should only contain 6-digit BINs. Do not include: - Full card numbers - CVV values - Expiration dates - Cardholder names - Full track data - Any other sensitive payment credential data Valid BIN value: ```text 411111 ``` Invalid values: ```text 4111111111111111 411-111 41111 4111111 ``` MCP must not invent BINs. The user must provide the exact BIN list, or the BINs must come from trusted account/business data. --- # Creating vs Editing BIN Profiles ## Creating Creating a BIN Profile establishes a new reusable BIN list. The key creation questions are: - What is the profile name? - What is the purpose? - Which exact 6-digit BINs should be included? - Should it be enabled? - Is it only a list, or will it later be used in advanced Payment Profile logic? --- ## Editing Editing a BIN Profile should be handled carefully because a BIN Profile may already be used by a Payment Profile. Important edit behavior: ```text If the bin_6 array is provided during edit, it replaces the existing BIN list. ``` It does not append a single BIN. It does not merge with the current list. If the MCP edits a BIN Profile and includes `bin_6`, the array must contain every BIN that should remain after the edit. This matters because removing or replacing BINs may change Payment Profile matching behavior if the BIN Profile is used in payment routing. --- # Common BIN Profile Examples ## Reporting BIN Profile ```text Name: High Decline BIN Review Purpose: Group user-provided BINs for decline-rate review and reporting. Payment behavior: None by itself. ``` ## Advanced Routing BIN Profile ```text Name: Business A Preferred BINs Purpose: Used by an advanced Payment Profile to route matching BINs to Business A Preferred Gateway Group. Payment behavior: Only applies when referenced by Payment Profile logic. ``` ## Advanced Blocking BIN Profile ```text Name: Blocked BINs Purpose: User-confirmed BIN list intended for blocking in a Payment Profile. Payment behavior: Only blocks if Payment Profile routes matches to action_abort_flow. ``` ## Review / Watchlist BIN Profile ```text Name: BIN Watchlist Purpose: Store BINs for review before deciding whether advanced routing is needed. Payment behavior: None by itself. ``` --- # When BIN Profiles Are Appropriate BIN Profiles are appropriate when: - The user has an exact BIN list. - The user wants to organize known BINs. - The user wants to report on known BIN groups. - The user wants to review a set of BINs. - The user has a clear advanced payment-routing need. - The user understands that Payment Profile logic is separate. --- # When Advanced BIN Routing Is Appropriate Advanced BIN routing may be appropriate when: - The user has known BIN-level approval data. - The user has a specific gateway strategy tied to BINs. - The user has a business/corp routing requirement. - The user has a confirmed risk policy tied to BINs. - The user has a fallback strategy. - The user understands the effect on payment processing. --- # When Advanced BIN Routing Is Not Appropriate MCP should avoid BIN-based Payment Profile logic when: - The user only wants to store a BIN list. - The user has not explained what should happen on BIN match. - The BIN list is speculative. - The user does not have advanced payment needs. - The user has not confirmed whether routing or blocking is desired. - The behavior can be handled more safely with normal gateway group routing. - Blocking has not been explicitly confirmed. Default assumption: ```text A BIN Profile is only a reusable BIN list unless the user explicitly asks to use it in advanced Payment Profile logic. ``` --- # Summary BIN Profiles exist to store and organize 6-digit credit card BIN lists. They are useful for: - Review - Reporting - Organization - Watchlists - Advanced Payment Profile filtering - Advanced Payment Profile routing - Advanced Payment Profile blocking when explicitly confirmed The most important MCP concepts are: ```text A BIN Profile does not block, route, or process payments by itself. Payment Profile use is advanced and should only be used for advanced payment needs. MCP must not invent BINs. MCP must not store full card numbers or sensitive payment data. MCP must clarify the intended behavior before recommending BIN-based payment routing or blocking. ``` --- Document Parent Directory * [Operations](https://revcent.com/documentation/markdown/mcp/operation/index.md) - AI/MCP details and overviews for operations available within the RevCent MCP.