When a software platform approaches you to enable payments for their merchant customers, the initial evaluation seems straightforward: verify the platform's technology, assess their security, review their onboarding processes. But beneath this surface lies a more complex question: Is this platform simply providing software, or are they operating as an unregistered Independent Sales Organization (ISO)?
Unlike traditional technology vendors, platforms that function as ISOs assume responsibilities for merchant relationships, pricing decisions, risk management, and payment routing. These operational realities carry regulatory obligations, liability exposure, and compliance requirements that many platforms don't recognize until they're facing enforcement actions or scheme violations.
This guide provides the complete assessment framework we use to evaluate platform merchants and distinguish legitimate software providers from businesses operating as de facto ISOs.
Understanding the ISO Classification
An Independent Sales Organization, as defined by Visa and Mastercard, performs specific functions in the payment acceptance chain. The classification isn't determined by what a business calls itself, but by what it actually does.
Legitimate software platforms: Companies that provide technology enabling merchants to accept payments, while the acquirer maintains direct relationships with merchants, controls pricing, and manages risk (low to medium compliance risk)
De facto ISOs: Platforms that control merchant onboarding, set pricing, manage merchant relationships, and make risk decisions while lacking ISO registration or proper oversight (high risk, regulatory exposure)
Card schemes require ISOs to register, maintain compliance programs, undergo audits, and accept liability for merchant activity. Platforms operating as ISOs without registration create exposure for acquirers, violate scheme rules, and misallocate risk across the payment chain.
The Complete Assessment Framework
Merchant Relationship Ownership and Control
Why it matters: The entity that owns the merchant relationship bears ISO responsibilities, regardless of contractual labels.
Software platforms might facilitate connections between merchants and acquirers, but when the platform owns the relationship, sets expectations, and controls communications, they're functioning as an ISO.
High-Risk Relationship Patterns
Platform as primary merchant contact:
- Merchants view the platform as their payment provider
- Platform handles all merchant support and troubleshooting
- Merchants have no direct relationship with the underlying acquirer
- Platform brand dominates all merchant-facing communications
Why this is high risk: When merchants don't know who their actual acquirer is, the platform is operating as the merchant's payment provider (ISO function).
Application and onboarding ownership:
- Platform collects merchant applications without acquirer involvement
- Platform makes initial underwriting decisions
- Platform controls merchant access to payment acceptance
- Merchants never interact with acquirer during onboarding
Why this is critical risk: Merchant onboarding and underwriting are core ISO functions. Platforms controlling these processes are operating as ISOs.
Ongoing merchant management:
- Platform handles merchant compliance requests
- Platform communicates policy changes and requirement updates
- Merchants contact platform (not acquirer) for all issues
- Platform manages merchant lifecycle without acquirer involvement
Why this is high risk: Ongoing merchant management responsibility indicates ISO operations, not software provision.
Merchant agreement structure:
- Platform's terms of service govern the merchant relationship
- Acquirer agreement is buried or presented as "backend infrastructure"
- Merchants believe they've contracted with the platform for payment services
- No direct contractual relationship between merchant and acquirer
Why this is critical risk: Contractual structure reveals who owns the merchant relationship. When the platform's agreement governs payments, the platform is the ISO.
Acceptable Relationship Patterns
Facilitated introduction:
- Platform introduces merchants to acquirer
- Acquirer evaluates and onboards merchant directly
- Merchant understands they're contracting with the acquirer
- Platform provides technology supporting the relationship
Transparent role communication:
- Merchants clearly understand the platform provides software
- Acquirer is identified as the payment services provider
- Direct communication channels exist between merchant and acquirer
- Platform support is limited to technical/software issues
Acquirer-owned onboarding:
- Acquirer reviews and approves all merchant applications
- Acquirer makes underwriting decisions
- Platform may collect information but doesn't control approval
- Merchant agreements are with acquirer (platform referenced as technology provider)
What to Request from Platform
Category
Documentation Needed
Merchant communications
- Review of merchant-facing materials (website, emails, support documentation)
- How the platform describes itself and its role
- Identification of the acquirer in merchant communications
- Support ticket examples showing who handles merchant issues
Onboarding process
- Complete merchant onboarding flow documentation
- Party responsible for application review and approval
- Merchant application forms and who they’re submitted to
- Underwriting process and decision ownership
Merchant agreements
- Platform's merchant terms of service
- Acquirer's merchant processing agreement
- Clarity of each party's role and responsibilities
- How agreements are presented to merchants during signup
Support structure
- Support tiers and responsibilities
- Examples of merchant support interactions
- Escalation paths for different issue types
- Direct communication channels between merchants and acquirer
Testing Protocol
- Merchant interview: If possible, speak with the platform's merchant customers to verify:
- Who do they think provides their payment processing?
- Who did they apply to for payment acceptance?
- Who do they contact when they have issues?
- Are they aware of the underlying acquirer?
- Mystery shopping: Review the platform's website and signup flow as if you're a merchant:
- Is the acquirer clearly identified?
- Who appears to be offering payment services?
- What agreements are you signing?
- Who owns the merchant relationship based on presentation?
- Communication review: Examine actual merchant communications over 3-6 months
Platform Assessment Checklist
- Merchants are clearly informed of acquirer's role during onboarding
- Acquirer reviews and approves merchant applications
- Merchant agreements clearly distinguish platform (technology) from acquirer (payment services)
- Direct communication exists between merchants and acquirer
- Platform doesn't present itself as the payment provider
- Merchants understand they have a relationship with both platform and acquirer
Red flag threshold:
- Merchants unaware of underlying acquirer = CRITICAL RISK
- Platform presents itself as payment provider = CRITICAL RISK
- Platform controls merchant onboarding without acquirer involvement = HIGH RISK
- No direct merchant-acquirer communication = HIGH RISK
Pricing Authority and Rate Setting
Why it matters: Pricing authority is one of the clearest indicators of ISO status. The entity that sets merchant rates is performing an ISO function.
Technology platforms may charge software fees, but when they set payment processing rates, they've crossed into ISO territory.
High-Risk Pricing Patterns
Platform sets processing rates:
- Platform determines the rates merchants pay for payment acceptance
- Merchants believe they're paying the platform for processing
- Platform changes processing rates without acquirer involvement
- Merchants negotiate rates with platform, not acquirer
Why this is critical risk: Setting payment processing rates is a definitive ISO function. Card schemes explicitly define this as ISO activity.
Opaque rate structures:
- Merchants cannot identify the acquirer's rate versus platform markup
- Single blended rate provided by platform
- No transparency into acquirer fees versus platform fees
- Platform bundles processing and software costs
Why this is high risk: Lack of rate transparency masks that the platform is setting processing rates, not just software fees.
Rate negotiation ownership:
- Platform sales team negotiates payment processing rates
- Merchants don't interact with acquirer on rate discussions
- Rate concessions or discounts come from platform
- Platform controls rate changes and merchant rate lifecycle
Why this is high risk: Rate negotiation control indicates the platform is selling payment services (ISO function), not software.
Revenue share structure:
- Platform receives percentage of payment processing revenue
- Revenue share not clearly distinguished from software fees
- Platform earnings increase with merchant processing volume
- Structure resembles traditional ISO revenue share
Why this is medium risk: Revenue share alone isn't determinative, but combined with other factors suggests ISO operations. The question is whether the platform shares in payment revenue or charges for software.
Acceptable Pricing Patterns
Separate fee structures:
- Platform charges clearly defined software/technology fees
- Acquirer sets and communicates payment processing rates
- Merchants understand they pay separately for software and processing
- Transparent breakdown of all fees
Acquirer rate authority:
- Acquirer establishes merchant processing rates
- Acquirer communicates rates directly to merchants
- Platform may receive referral fees or revenue share but doesn't set processing rates
- Rate changes are communicated by acquirer
Transparent technology fees:
- Fixed monthly software subscription (e.g., $200/month for platform access)
- Per-transaction technology fee clearly distinguished from processing (e.g., $0.05 per transaction to platform, plus acquirer's processing fees)
- SaaS-style fee model
- No relationship between platform fees and processing volume
What to Request from Platform
Category
Documentation Needed
Merchant rate documentation
- Rate sheets provided to merchants
- Breakdown of platform fees versus acquirer fees
- Sample merchant invoices or statements
- How processing rates are presented to merchants
Rate authority
- Party responsible for setting payment processing rates
- Process for rate negotiations with merchants
- Authority to change rates
- Revenue split agreements with acquirer
Fee structure
- Documentation of all fees charged to merchants
- Justification for revenue share arrangements
- Software fees versus payment fees
- Volume-based fee structures
Sales process
- Sales materials used with prospective merchants
- How payment acceptance rates are positioned
- Who merchants negotiate with on rates
- Rate approval workflows
Platform Assessment Checklist
- Acquirer sets all payment processing rates
- Platform fees are clearly separated from processing fees
- Merchants receive transparent breakdown of all costs
- Platform doesn't negotiate payment processing rates
- Software fees follow SaaS or technology fee models
- Any revenue share is clearly documented and doesn't involve rate-setting
Red flag threshold:
- Platform sets merchant processing rates = CRITICAL RISK (definitive ISO function)
- Blended rates with no transparency = HIGH RISK
- Platform negotiates processing rates with merchants = HIGH RISK
- Merchants believe platform controls their payment costs = HIGH RISK
Payment Routing and Transaction Control
Why it matters: Control over payment routing, processor selection, and transaction flow indicates operational control over payment acceptance (ISO function).
Platforms providing neutral technology allow merchants and acquirers to control routing. Platforms dictating routing decisions are operating the payment infrastructure.
High-Risk Routing Patterns
Platform controls processor routing:
- Platform determines which processor or acquirer handles transactions
- Platform switches merchants between processors without merchant input
- Merchants have no visibility into routing logic
- Platform makes routing decisions based on its own economics
Why this is critical risk: Routing authority means the platform controls payment acceptance operations, not just provides technology.
Exclusive routing relationships:
- Platform only routes to processors they select
- Merchants cannot choose their own acquirer
- Platform prohibits merchant from using other payment processors
- Routing exclusivity benefits platform commercially
Why this is high risk: Limiting merchant choice and controlling relationships indicates ISO operations.
Opaque transaction flow:
- Merchants don't know which acquirer or processor handles their transactions
- Platform aggregates transactions across multiple merchants
- Settlement structure obscures individual merchant transaction flow
- Platform controls the technical payment infrastructure end-to-end
Why this is medium risk: While platforms may legitimately manage technical infrastructure, complete opacity about transaction flow masks ISO-like control.
Platform-level merchant aggregation:
- Multiple platform merchants appear as one entity to the processor
- Platform holds the merchant account
- Individual merchants are sub-merchants without direct processor relationships
- Platform bears liability for sub-merchant activity
Why this is critical risk: This is payment facilitator (PayFac) or aggregator model, which requires specific registration and compliance. If platform isn't registered as PayFac, this is severe regulatory exposure.
Acceptable Routing Patterns
Merchant choice:
- Merchants select their preferred acquirer/processor
- Platform technology integrates with multiple processors
- Merchants can switch processors without changing platforms
- No commercial incentive for platform in routing decisions
Transparent routing:
- Merchants understand where their transactions are processed
- Direct relationships exist between merchant and processor
- Platform facilitates connection but doesn't control it
- Technical infrastructure is neutral
Acquirer-controlled routing:
- Acquirer makes routing decisions for their merchants
- Platform respects acquirer's routing preferences
- Technology supports acquirer's operations
- No platform override of acquirer routing
What to Request from Platform
Category
Documentation Needed
Routing logic
- Documentation of how transactions are routed
- Processor selection criteria
- Merchant visibility into routing
- Routing decision ownership
Processor relationships
- List of supported processors/acquirers
- Exclusivity arrangements
- Commercial agreements affecting routing
- Merchant ability to choose processors
Transaction flow
- Diagram showing transaction flow from merchant to processor
- Merchant account structure
- Aggregation or individual processing
- Settlement flow documentation
Technical control
- Platform's role in payment infrastructure
- Ability for merchants to connect directly to processors
- Platform override capabilities
- Merchant control over transaction handling
Platform Assessment Checklist
- Merchants can select their preferred acquirer/processor
- Platform integrates with multiple processors (no exclusivity)
- Transparent transaction routing and flow
- Merchants have direct relationships with processors
- No aggregation or sub-merchant structure (unless properly registered as PayFac)
- Platform doesn't make routing decisions based on commercial incentives
Red flag threshold:
- Platform controls all routing decisions = HIGH RISK
- Merchant aggregation without PayFac registration = CRITICAL RISK
- Exclusive processor relationships limiting merchant choice = HIGH RISK
- Opaque routing with no merchant visibility = MEDIUM RISK
Risk Management and Underwriting Authority
Why it matters: Underwriting merchants and managing risk are core ISO functions. Platforms making these decisions are operating as ISOs.
Technology platforms may have fraud detection tools, but when they decide which merchants can accept payments, they're performing ISO functions.
High-Risk Authority Patterns
Platform underwriting decisions:
- Platform approves or declines merchant applications
- Platform determines merchant risk levels
- Platform sets transaction limits or processing restrictions
- Acquirer rubber-stamps platform decisions
Why this is critical risk: Merchant underwriting is a definitive ISO function. Platforms making approval decisions are operating as ISOs regardless of contracts.
Ongoing risk management:
- Platform monitors merchant activity for risk
- Platform makes decisions to suspend or terminate merchants
- Platform controls merchant access to payment acceptance
- Platform handles merchant compliance issues
Why this is high risk: Ongoing risk management authority indicates ISO operations.
Reserve and hold authority:
- Platform determines reserve requirements for merchants
- Platform controls when funds are released to merchants
- Platform makes decisions to hold or delay merchant payouts
- Platform sets risk-based restrictions on merchant accounts
Why this is high risk: Control over merchant funds and risk-based restrictions are ISO functions.
Chargeback and dispute management:
- Platform manages chargeback process with minimal acquirer involvement
- Platform makes decisions on chargeback liability
- Platform handles merchant dispute resolution
- Merchants interact only with platform on chargebacks
Why this is medium risk: While some operational chargeback handling is acceptable, decision-making authority over liability indicates ISO functions.
Acceptable Risk Patterns
Acquirer underwriting:
- Acquirer reviews all merchant applications
- Acquirer makes approval/decline decisions
- Platform may collect information or provide risk scoring tools
- Final authority rests with acquirer
Platform risk tools:
- Platform provides fraud detection or risk monitoring technology
- Tools generate alerts or recommendations
- Acquirer or merchant makes final risk decisions
- Technology supports but doesn't replace acquirer's risk management
Transparent risk allocation:
- Clear documentation of who bears merchant risk
- Acquirer sets reserve requirements
- Acquirer controls merchant suspensions/terminations
- Platform's role is technology provision, not risk decision-making
What to Request from Platform
Category
Documentation Needed
Underwriting process
- Complete underwriting workflow
- Decision authority documentation
- Platform's role versus acquirer's role
- Approval/decline authority
Risk management
- Ongoing merchant monitoring processes
- Authority to suspend or terminate merchants
- Risk-based restriction protocols
- Merchant limit-setting procedures
Fund control
- Reserve requirement decision process
- Payout hold authority
- Fund release protocols
- Control over merchant cash flow
Chargeback handling
- Chargeback management workflow
- Decision authority on disputes
- Liability allocation
- Merchant communication on chargebacks
Platform Assessment Checklist
- Acquirer makes all underwriting decisions
- Platform provides risk tools but doesn't make risk decisions
- Clear risk allocation with acquirer bearing merchant risk
- Acquirer controls merchant suspensions, terminations, and restrictions
- Platform doesn't determine reserve requirements or hold funds
- Acquirer manages chargeback liability and disputes
Red flag threshold:
- Platform makes merchant approval/decline decisions = CRITICAL RISK
- Platform controls merchant access to payment acceptance = CRITICAL RISK
- Platform determines reserves or holds funds = HIGH RISK
- Platform makes chargeback liability decisions = MEDIUM RISK
Compliance Responsibility and Regulatory Positioning
Why it matters: ISOs bear compliance responsibilities including scheme rules, Know Your Customer/Anti-Money Laundering (KYC/AML), and merchant monitoring. Platforms assuming these duties are operating as ISOs.
The allocation of compliance responsibility reveals the substance of the relationship beyond contractual labels.
High-Risk Compliance Patterns
Platform compliance ownership:
- Platform represents to merchants that they handle compliance
- Platform conducts KYC/AML on merchants
- Platform is responsible for scheme rule compliance
- Platform handles regulatory reporting for merchant activity
Why this is critical risk: Compliance responsibility is a core ISO function. Platforms bearing this responsibility are operating as ISOs.
Scheme registration positioning:
- Platform is registered with card schemes
- Platform holds scheme credentials or certifications
- Platform represents itself as scheme-compliant entity
- Platform is listed as responsible party with schemes
Why this is critical risk: Scheme registration in a capacity beyond technology provider indicates ISO operations.
Regulatory compliance burden:
- Platform implements AML transaction monitoring
- Platform files Suspicious Activity Reports (SARs) for merchant activity
- Platform maintains compliance programs for merchant portfolio
- Platform is subject to regulatory examination for payment activities
Why this is high risk: Regulatory compliance programs for merchant activity are ISO responsibilities.
Indemnification structure:
- Platform indemnifies acquirer for merchant activity
- Platform bears financial liability for merchant defaults
- Platform assumes scheme fine liability
- Risk transfer suggests platform is the ISO
Why this is medium risk: While indemnification doesn't definitively prove ISO status, it indicates the platform is bearing ISO-level risk.
Acceptable Compliance Patterns
Acquirer compliance ownership:
- Acquirer is responsible for all scheme compliance
- Acquirer conducts merchant KYC/AML
- Acquirer handles regulatory reporting
- Platform supports compliance but doesn't own it
Technology enablement:
- Platform provides compliance tools (KYC automation, transaction monitoring)
- Tools support acquirer's compliance program
- Acquirer remains responsible for compliance decisions
- Platform doesn't bear compliance liability
Clear regulatory positioning:
- Platform registered appropriately with schemes (as technology provider if required)
- No representation of compliance responsibility to merchants
- Acquirer identified as responsible regulated entity
- Compliance obligations clearly allocated in contracts
What to Request from Platform
Category
Documentation Needed
Compliance structure
- Documentation of compliance responsibilities
- KYC/AML program ownership
- Scheme compliance responsibility
- Regulatory reporting obligations
Scheme registration
- Card scheme registration status and capacity
- Certifications or credentials held
- How platform is positioned with schemes
- Responsible party designation
Merchant representations
- How compliance is communicated to merchants
- Compliance support materials
- Responsibility for compliance failures
- Merchant compliance obligations
Risk allocation
- Indemnification provisions
- Liability for merchant defaults
- Scheme fine responsibility
- Regulatory examination exposure
Platform Assessment Checklist
- Acquirer owns all compliance responsibilities
- Platform provides compliance tools but doesn't own compliance
- Appropriate scheme registration (technology provider, not ISO/MSP)
- Acquirer conducts merchant KYC/AML
- Acquirer bears regulatory and scheme compliance liability
- Clear allocation of compliance obligations in agreements
Red flag threshold:
- Platform represents compliance responsibility to merchants = CRITICAL RISK
- Platform registered with schemes as ISO/MSP without proper ISO program = CRITICAL RISK
- Platform conducts KYC/AML as responsible party = HIGH RISK
- Platform indemnifies acquirer for all merchant risk = MEDIUM RISK
What Good Looks Like: The Compliant Platform Relationship
When all elements align properly, a legitimate software platform partnership presents this profile:
Documentation Package
Business Model
- Platform provides clearly defined software or technology services
- Revenue model based on software fees (SaaS, per-transaction technology fee, etc.)
- No revenue from payment processing rate markups
- Transparent distinction between platform fees and payment fees
- Documentation supports technology provider positioning
Merchant Relationships
- Acquirer maintains direct merchant relationships
- Merchants understand they contract with acquirer for payment services
- Platform role is clearly communicated as technology provider
- Direct communication channels exist between merchant and acquirer
- Acquirer handles merchant support for payment-related issues
Operational Control
- Acquirer sets payment processing rates
- Acquirer makes merchant underwriting decisions
- Acquirer controls merchant access to payment acceptance
- Acquirer manages risk, reserves, and compliance
- Platform provides tools supporting these functions but doesn't control them
Compliance
- Acquirer registered as ISO/Member Service Provider (MSP) with card schemes
- Acquirer conducts merchant KYC/AML
- Acquirer responsible for scheme compliance
- Platform may have technology provider registration only
- Clear compliance responsibility allocation
Example: Compliant Platform Profile
Company: PaymentTech Solutions
Model: SaaS platform providing payment integration technology
Services provided:
- API integrations with multiple processors/acquirers
- Payment gateway technology
- Transaction routing optimization tools
- Merchant dashboard and reporting
- Fraud detection algorithms
Revenue model:
- $300/month software subscription per merchant
- $0.05 per transaction technology fee
- Optional premium features (advanced reporting, analytics)
- No revenue from payment processing rates
Merchant relationship:
- Merchants apply directly to acquirer for payment acceptance
- Acquirer reviews applications and makes approval decisions
- Merchant agreement is with acquirer (platform referenced as technology provider)
- Acquirer sets payment processing rates
- Platform invoices merchants separately for software services
Operational structure:
- Acquirer underwrites and approves all merchants
- Acquirer determines merchant rates
- Merchants can use platform technology with any supported acquirer
- Acquirer controls merchant access, suspensions, and risk management
- Platform provides technology infrastructure
Compliance:
- Acquirer handles all KYC/AML
- Acquirer responsible for scheme compliance
- Acquirer conducts merchant monitoring
- Platform provides compliance tools (transaction monitoring, KYC automation)
- Platform registered with schemes as technology provider only
This profile represents acceptable risk and appropriate classification.
Common Classification Errors
Mistake: Accepting the "we're just a platform" assertion
The problem: Assuming platform self-identification is accurate without functional verification.
What to do: Examine operational reality. The label doesn't matter. Who controls merchant relationships, rates, underwriting, and risk? Those functions define ISO status.
Mistake: Relying solely on contract language
The problem: Contracts describe compliant structures while actual operations differ. Platform may be contractually a "technology provider" while functionally operating as an ISO.
What to do: Verify actual operational practices. Interview merchants, review communications, examine merchant perception, test the signup flow. Operational reality outweighs contract terms.
Mistake: Confusing revenue share with ISO status
The problem: Assuming revenue share arrangements automatically make a platform an ISO, or assuming lack of revenue share means they're not an ISO.
What to do: Revenue share is one factor but not determinative. Focus on functional control: rate authority, merchant relationships, underwriting, risk management. Platforms can have revenue share arrangements while remaining technology providers if they don't control ISO functions.
Mistake: Ignoring merchant perception
The problem: Focusing on backend agreements between platform and acquirer while ignoring how merchants perceive the relationship.
What to do: Merchant perception is critical. If merchants believe the platform is their payment provider, the platform is functioning as an ISO regardless of backend contracts. Mystery shop the merchant experience.
Mistake: Accepting partial compliance
The problem: Platform may have appropriate controls in some areas (e.g., transparent rates) while controlling ISO functions in others (e.g., merchant underwriting).
What to do: ISO determination requires evaluating all factors. One compliant element doesn't offset control in other areas. A platform that sets transparent rates but controls underwriting is still an ISO.
Mistake: Not escalating PayFac/aggregation structures
The problem: Accepting merchant aggregation or sub-merchant models without verifying proper PayFac registration and compliance programs.
What to do: Merchant aggregation (platform holds master merchant account, sub-merchants process under it) requires specific regulatory registration and robust compliance programs. Unregistered aggregation is critical risk. Verify payment facilitator registration immediately.
The Critical Question
When evaluating whether a platform is operating as an ISO, ask:
"If the acquirer stopped working with this platform tomorrow, would the merchants know who to contact to continue accepting payments?"
If yes because merchants have direct acquirer relationships, understand the acquirer provides payment services, and can transition to another platform without losing payment acceptance, the platform is likely operating as a technology provider.
If no because merchants think the platform is their payment provider, have no relationship with the acquirer, and would lose payment acceptance if they left the platform, the platform is operating as an ISO regardless of how they're labeled.
This question captures the essence of ISO operations: merchant relationship ownership and operational control.
Ballerine's Role
Ballerine provides the infrastructure to make this complex assessment systematic: automated monitoring of how platforms present themselves to merchants, ecosystem mapping to reveal platform merchant relationships and operational patterns, and continuous compliance verification to detect when platforms evolve from technology providers into de facto ISOs post-onboarding.
Our merchant monitoring capabilities maintain visibility across your platform portfolio, detecting operational changes that shift risk profiles. When platforms add rate control, expand into underwriting, or take over merchant relationships, these changes are identified before regulatory exposure accumulates.
We help payment organizations avoid the common trap: onboarding a platform as a technology provider while they're functionally operating as an unregistered ISO. For sophisticated platform risk assessment capabilities, our tools analyze the operational realities that determine classification.
.png)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.png)
