slug: slash
provider: Slash
generated_by: planning/capability-mapping/scripts/classify_capabilities.py
model: claude-opus-5
frame:
- Banking & Capital Markets
min_confidence: 0.7
capability_model:
  source: https://github.com/vincentmakes/turbo-ea-capabilities
  license: CC-BY-4.0
  attribution: Turbo EA Capabilities by Vincent Verdet — Turbo EA, https://github.com/vincentmakes/turbo-ea-capabilities,
    CC BY 4.0
  notice: NOTICE
edge_count: 7
edges:
- tag: Developer Application
  spec_file: slash-developer-application-api-openapi.yml
  capability_id: BC-4270.40
  capability_id_l1: BC-4270
  capability_name: Developer Identity & Credential Management
  confidence: 0.85
  evidence: POST /developer-application/{developerApplicationId}/secret — "Create or regenerate a DeveloperApplication's
    OAuthClientSecret"
  reason: Lifecycle of developer applications and OAuth client secrets is squarely developer identity
    and credential management.
- tag: Invoice
  spec_file: slash-invoice-api-openapi.yml
  capability_id: BC-200.30
  capability_id_l1: BC-200
  capability_name: Accounts Receivable Management
  confidence: 0.8
  evidence: POST /invoice; POST /invoice/{invoiceId}/void; POST /invoice/{invoiceId}/reconcile; POST /invoice/{invoiceId}/send-reminder
  reason: Customer invoice issuance, reminders, reconciliation and payment-method configuration is accounts
    receivable / customer invoicing.
- tag: Developer Account
  spec_file: slash-developer-account-api-openapi.yml
  capability_id: BC-4270.40
  capability_id_l1: BC-4270
  capability_name: Developer Identity & Credential Management
  confidence: 0.78
  evidence: POST /developer-account/{developerAccountId}/application — "Create a DeveloperApplication";
    schema DeveloperApplication.PermissionKeyTypes.PermissionPolicyKey
  reason: Registers developer applications with permission policies — developer credential/identity administration
    for the API ecosystem, not a banking business capability.
- tag: Card Group
  spec_file: slash-card-group-api-openapi.yml
  capability_id: BC-1340
  capability_id_l1: BC-1340
  capability_name: Payments & Card Management
  confidence: 0.75
  evidence: POST /card-group; PUT /card-group/{cardGroupId}/spending-constraint; schemas SpendingConstraint,
    CardGroupUtilization
  reason: Operations create and administer groups of corporate cards with spending constraints and utilisation
    views — card programme administration within Payments & Card Management. Evidence does not clearly
    single out issuance vs transaction processing, so only the L1 is asserted.
- tag: Transaction
  spec_file: slash-transaction-api-openapi.yml
  capability_id: BC-1340.70
  capability_id_l1: BC-1340
  capability_name: Card Transaction Processing Management
  confidence: 0.75
  evidence: GET /transaction/{transactionId}/fee-details; schemas TransactionMerchant, TransactionCashbackInfo,
    Card, CardStatus, TransactionFxFeeInfo, TransactionDetailedStatus
  reason: Operations expose card transaction records with merchant, card, status, fee and FX-fee detail
    on a corporate card issuer's platform, i.e. card transaction processing/servicing. Some ambiguity
    as the surface is read-oriented (could be viewed as account transaction reporting), hence 0.75.
- tag: Account
  spec_file: slash-account-api-openapi.yml
  capability_id: BC-1330.10
  capability_id_l1: BC-1330
  capability_name: Deposit Account Management
  confidence: 0.7
  evidence: GET /account/{accountId}/balance; schemas "Account", "Balance", "Money"
  reason: Vendor provides business checking accounts; the tag exposes account retrieval and balance enquiry,
    which is demand-deposit/current-account information. Mapped to Deposit Account Management, with some
    ambiguity as part of the surface (authorization-webhook) is integration plumbing.
- tag: Card
  spec_file: slash-card-api-openapi.yml
  capability_id: BC-1340.60
  capability_id_l1: BC-1340
  capability_name: Card Issuance Management
  confidence: 0.7
  evidence: POST /card; "GET /card/{cardId}/utilization"; schemas "Card", "CardStatus", "SpendingConstraint"
  reason: Creates and manages virtual/physical corporate cards including status and spending constraints
    — card issuance and in-life card control, matching Card Issuance Management. Not transaction switching/authorisation,
    so .70 is a weaker fit; some ambiguity remains between the two sub-capabilities.