Pre-screened acquisition service system and method

Abstract

A system for the near real-time exchange of regulatory-compliant and privacy-compliant consumer credit data between two parties (i.e., a credit bureau and a financial services institution) that facilitates the financial services institutions (i.e., lenders) to directly identify audiences of pre-screened consumers (i.e., prospects) to offer credit products without requiring the intervention of a third party, such as an agent of the bureau, employs a data clean room to facilitate the necessary data exchange. The clean room enables and expedites the presentment of firm offer of credit pre-screened offers across authenticated or authenticatable offline and digital online channels, thereby making credit available to consumers in a more timely and efficient manner while protecting consumer privacy.

Description

PRE-SCREENED ACQUISITION SERVICE SYSTEM AND METHODCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of US provisional patent application no. 63 / 657,630, filed on June 7, 2024, and US provisional patent application no. 63 / 747,753, filed on January 21, 2025. Such applications are incorporated by reference as if fully set forth herein.BACKGROUN D OF TH E INVENTION

[0002] Presently, regulated financial services institutions (i.e., lenders) contend with antiquated laws crafted during an era when tape processing of transactions was commonplace. This predicament manifests in prolonged processing times and data latency for numerous routine tasks, often spanning days, hindering the timely integration of recent updates such as consumers requests that they not be included in offers, i.e., opt-outs. Addressing this issue would streamline regulatory processes and would foster enhanced compute efficiency and expediency.

[0003] In addition, financial service institutions have been limited in their ability to reach credit-qualified consumers and present them with pre-screened credit offers. This limits credit availability awareness for consumers and limits their choices for financing options. Addressing this issue would expedite the presentment of firm offer of credit pre-screened offers across authenticated or authenticatable digital online channels, thereby making credit available to consumers in a more timely and efficient manner.

[0004] A critical limitation of existing systems is that, in order to avoid a time-consuming process of stripping Pll (Personally Identifiable Information) from consumer credit data records so that they can be shared, they instead rely on an "agent of the bureau," which is a trusted third party that allows processing of data without sharing Pll between the two parties exchanging information (i.e., the credit bureau and the financial service institution). As a result, files must be transferred back and forth between the financial services institution and the agent of the bureau, as well as between the credit bureau and the agent of the bureau. This cumbersome process adds time and expense to the generation process for creating an audience for pre-screened offers. These applications essentially engage in voluminous data shuffling between systems with each query.

[0005] In addition, prior approaches to offer presentment (e.g., presentment of a pre-screened firm offer of credit) have historically been limited to offline channels (e.g., postal mail or call centers) and / or owned and operated digital channels (i.e., bank website or mobile apps, or cobrand or partner websites or apps). This limitation constrains a financial service provider's ability to reach credit-qualified consumers and to present them with pre-screened credit offers, thereby obfuscating awareness of credit availability for consumers and limits their choices for financing options.SUMMARY OF THE INVENTION

[0006] The present invention is directed to a system and method for the real-time or near realtime exchange of regulatory-compliant and privacy-compliant consumer credit data between two parties (i.e., a credit bureau and a financial services institution) that allows the financial services institutions (i.e., lenders) to directly identify audiences of pre-screened consumers (i.e., prospects) to offer credit products without requiring the intervention of a third party, such as an agent of the bureau. This improvement is achieved in part by employing data clean room technology in the systems and methods according to the invention.

[0007] In certain embodiments, the invention enables and expedites the presentment of firm offer of credit pre-screened offers across authenticated or authenticatable digital online channels, thereby making credit available to consumers in a more timely and efficient manner.

[0008] In certain embodiments, the invention empowers financial service institutions to securely process regulated data autonomously, foregoing the need for third-party (i.e., agent of the bureau) involvement.

[0009] In certain embodiments, the invention reduces processing times from days to hours or less, enhancing efficiency for financial service institutions, and enables real-time or near realtime offer presentment by continually scanning regulated credit eligibility data. Thus in certain embodiments the system can provide periodic or constant updates to the service being provided.

[0010] In certain embodiments, the invention obviates the necessity of moving / transferring regulated consumer credit data (i.e., from credit bureaus to third-party agents and / or financial service institutions), thereby fortifying consumer data protections through centralized data management and better protecting consumer privacy.

[0011] In certain embodiments, the invention is better than existing systems by being more secure (due to less data movement / replication), faster (real-time or near real-time vs. multiple days of processing time), and cheaper (fewer data processing resources / costs).

[0012] These and other features, objects and advantages of the present invention will become better understood from a consideration of the following detailed description of the preferred embodiments and appended claims in conjunction with the drawings as described following:BRIEF DESCRIPTION OF DRAWINGS

[0013] Fig. 1 is an architectural, swim lane diagram providing an overview of a system according to an embodiment of the invention.

[0014] Fig. 2 is a diagram of a computing system component of a compute cluster used for the implementation of an embodiment of the invention.DETAILED DESCRIPTION OF THE INVENTION

[0015] Before the present invention is described in further detail, it should be understood that the invention is not limited to the particular embodiments described, and that the terms used in describing the particular embodiments are for the purpose of describing those particular embodiments only, and are not intended to be limiting, since the scope of the present invention will be limited only by the claims.

[0016] The invention in various embodiments utilizes data clean room technology. A data clean room is a secure environment that allows multiple parties to combine and analyze their respective datasets without directly sharing or exposing the raw data. It works by providing a controlled space where data from different sources can be pooled and analyzed collectively, while maintaining strict privacy and security protocols. Typically, only aggregated results or insights are made available to participants, ensuring that individual-level data remains protected, or certain columns are protected from disclosure to other parties. Clean rooms use advanced encryption, access controls, and data governance measures to prevent unauthorized data access or leakage. This approach enables organizations to gain valuable insights from collaborative data analysis while complying with data protection regulations and preserving customer privacy. Data clean rooms are particularly useful where data sensitivity and regulatory compliance are critical concerns.

[0017] The two data clean rooms shown in Fig. 1 are a central component of the platform that implements an embodiment of the invention. The data clean rooms facilitate secure, compliantdata sharing and processing between financial institutions and credit bureaus without exposing personally identifiable information (PI I), and without requiring an agent of the bureau as an intermediary. The data clean rooms utilize encryption, differential privacy, and other data protection techniques to ensure privacy and compliance. The data clean rooms are configurable such that one or more parties can utilize a given data clean room for activities such as querying data, one or more parties can restrict data element access and usage with control permissions and / or facilitate data clean room services such as identity resolution services. The first clean room 20 (at the top of the figure) is part of the "audience building" component of the invention, and the second clean room 22 (at the bottom of the figure) is part of the "audience presentment" component of the invention. Audience building is the configuration of the consumers to whom an offer is to be made and their associated required data, that is, the process of putting together a list of potential consumers for pre-approved offers of credit. Presentment or activation is the actual making of the offer of credit, that is, the process of matching those consumers with the necessary information by which they may be contacted, including by online contact, in order to receive the offer. The first clean room facilitates sharing between a financial services provider and a credit bureau, while the second clean room facilitates sharing between a financial services provider and a publisher.

[0018] Fig. 1 is a swim lane diagram showing components / functions of the four separate participants in the overall methods / systems of certain embodiments of the invention. A publisher 10 is the operator of the website or other media through which the offer is to be made (aka presented). The FinServ 12 is a financial institution and its related data and computing hardware. A service provider 14 intermediates the services described herein. Service provider 14 provides identity services as utilized in an embodiment of the invention. The Bureau 16 is a credit bureau and its related data and computing hardware.

[0019] Service provider 14 provides identity resolution services utilizing an identity graph, in order to accurately match consumer data between the financial institutions and the credit bureaus. An identity graph is a database that connects various data connected to a single user profile, enabling organizations to track and understand user behavior across different platforms and devices. The identifiers that are matched to resolved identities form a part of the identity graph. The graph is formed of nodes that store data, and edges that connect the data to represent relationships between data (i.e., data items that pertain to the same entity). An identity data graph is a data structure that may contain a comprehensive representation of anindividual consumer's digital identity, created by connecting various data points and interactions across multiple platforms and touchpoints. It aggregates and links information from diverse sources such as online accounts, social media profiles, purchase history, device usage, and offline interactions. This interconnected network of data provides a holistic view of a person's preferences, behaviors, and characteristics. Identity graphs use advanced data matching and resolution techniques to reconcile disparate data points and attribute them to a single user profile. This unified view enables providers to deliver more personalized experiences, improve customer targeting, and enhance cross-channel messaging efforts. However, protection of privacy in the use of identity graphs is critical, since the creation and use of identity graphs involves collecting and synthesizing large amounts of personally identifiable information (PH).

[0020] Identity graphs are often differentiated as being first-party, second-party, or third-party graphs. A first-party identity graph is one that is created and owned by a single organization using data collected directly from the users with which it interacts. A second-party identity graph is the first-party graph of a different organization; data may be shared from second-party identity graphs through a partnership between two or more organizations sharing their first- party data with each other. Third-party identity graphs, such as the identity graph of service provider 14, contain data compiled by data aggregators using data from multiple sources, generally without direct relationships with the users about whom they collect data. The owners of these third-party identity graphs may provide services to the owners of first-party graphs, whereby the first-party graphs are improved in various ways using data from the provider's more comprehensive third-party graph.

[0021] The consolidation of an individual user's identifiable information, touchpoints, and devices used by the individual into data graphs is a central aspect to effective messaging. To further support such messaging, user data may be divided into segments. Segmentation refers to the process of dividing a broad user base into smaller, more distinct groups of users based on shared characteristics. These groups, or segments, typically share similar needs, preferences, behaviors, or demographic traits. Segments may be based on, for example, demographics (age, gender, income, education, etc.); psychographics (lifestyle, values, interests, etc.); behavioral patterns (purchasing habits, brand loyalty, etc.); and geographic location (city, state, country, etc.). Traditionally, segmentation has been achieved in a number of different ways, including cluster analysis, decision trees, neural networks, and rule-based segmentation.

[0022] The identity service of service provider 14 may be accessed through an identity application programming interface (API) 18 call from either the FinServ 12 or Bureau 16. Service provider 14 leverages its identity graph to accurately match consumer data between financial institutions 14 and credit bureaus 16. It ensures, for example, that pre-screened offers are targeted to the right consumers based on up-to-date, privacy- and regulatory-compliant data.

[0023] Digital offer presentation is responsible for delivering pre-screened offers to consumers across various digital channels. These channels may include, for example, any number of publishers 10. In general, and as previously noted, a publisher 10 is an entity within a programmatic environment that owns or manages digital properties where messages may be displayed. These properties typically include websites, mobile apps, streaming platforms, or other digital media channels that attract audiences. Publishers make their inventory available through various programmatic platforms, such as supply-side platforms (SSPs) or ad exchanges. They offer the opportunity to reach their audience by selling space programmatically, often in real-time auctions. Publishers play a crucial role in the programmatic ecosystem by providing the digital real estate where messages appear, as well as valuable audience data that helps the targeting of effective campaigns. Their goal is to maximize the revenue generated from their inventory while maintaining a balance between user experience and messaging effectiveness.

[0024] Digital offer presentation integrates with various digital channels, such as one or more publishers 10, via APIs to deliver pre-screened offers to consumers through these channels. Interactions with pre-screened offers by consumers (e.g., clocks, views) are tracked and reported back to the FinServ 12 for campaign analysis. The FinServ 12 receives only an output that represents the overlap between the identifiers and the PH required for direct mail distribution, in order to protect consumer privacy. Publishers 10, in various embodiments, may include direct publishers and marketplace publishers.

[0025] Compliance and audit ensures that all data processing and offer presentments follow applicable and relevant regulations, which may include, for example, the EU's General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and the US federal Fair Credit Reporting Act (FCRA). Compliance and audit logs all operations for audit purposes and provides reporting tools for regulatory oversight. Compliance and audit provides tools for generating compliance reports and audit trails, which can be shared with regulatory bodies as needed. Real-time compliance checks may be performed by integration with externalcompliance databases and services to perform real-time checks during data processing and offer presentation, ensuring ongoing compliance with changing regulations.

[0026] FinServ 12 servers submit pre-screened consumer data to the platform maintained by service provider 14 via secure APIs. The data is encrypted and processed within first data clean room 20. Financial institution systems 12 interact with offer management through single sign- on (SSO) technology, ensuring secure and convenient access to campaign management tools.

[0027] Credit bureaus 16 interact with the platform of service provider 14 by sharing consumer credit data with the platform using secure data exchange protocols that comply with industry standards. Data is anonymized before being processed in the first data clean room 20. The platform queries credit bureau data in real time via APIs to validate consumer eligibility for prescreened offers based on the latest credit information. None of the data is hosted, however, by the service provider 14. Data can be stored in different cloud providers and different technologies in cloud computing environments, such as Databricks or Snowflake, although the invention is not so limited.

[0028] For identification purposes, an embedded pseudonymous identifier (which is hidden from the financial institutions) is automatically affixed to the data sets. An example of such an identifier is the RampID® identifier used by LiveRamp, Inc. of San Francisco, California. Throughout the data exploration process, queries are persistently logged, while robust safeguards within the data clean rooms, such as thresholds and hidden columns, ensure comprehensive data privacy protection. Upon finalizing the desired dataset (credit prescreened consumers in this case for the first data clean room 20), queries undergo approval by the credit bureau 16. The data (the targeted pre-screened consumer audience) is then activated for the end client (aka FinServ 12) with automated implementation of net-downs, i.e., the calculation of the actual cost of messaging placements (aka presentments) after applying various discounts, fees, and adjustments, enhancing both security and efficiency.

[0029] Following the generation / finalization of the pre-screened audience, the FinServ utilizes the second data clean room 22 to determine the authenticated and certifiable reach across publishers 10 (directly or via the provider's marketplace) to finalize their digital media buy orders. Publishers 10 with buy orders whose authenticated (i.e. logged-in) consumers arrive on their digital properties (i.e., digital device / screen, in-app, etc.) are presented with a prescreened offer (aka "firm offer of credit presentment"). Following presentment of each prescreened offer to a consumer, the publisher 10 time / date stamps to certify presentment of the prescreenedoffer and utilizes the service provider's data clean room 22 infrastructure to remit the certified presentment back to the FinServ 12, who retains the necessary data for proof of FCRA regulatory compliance.

[0030] With continued reference to Fig. 1, the audience building process may now be described in more detail. During the audience building process utilizing the first data clean room 20, bureau data 24 is provided from credit bureau 16 systems and eventually provided to the first data clean room 20. The data may be provided in a tabular (i.e., rows and columns) format. As part of this data share, the credit bureau 16 systems may indicate which columns in the data may not be shared within the data clean room with collaborators.

[0031] The identity resolution service of the service provider 14 uses its identity graph to run the identity process against the credit bureau data set 24 by an API call at identity API 18, depicted in Fig. 1 as 18a. The purpose is to uniquely identify individual consumers within this data set, based on the comprehensive data found in the identity graph. The identity graph may, for example, contain data concerning all or nearly all consumers within a relevant geographic or geopolitical area. The service provider 14 identity graph contains its own provider identifiers to resolve the identity of consumers, and may apply its provider identifiers to create a crossreference table 26, which contains a matching between the internal identifiers used by the Bureau (bureau identifiers) and those used by the identity graph (provider identifiers).

[0032] Meanwhile, the FinServ 12 is also interacting with the first data clean room 20. The FinServ 12 begins with its own suppression list 28 to build a list of consumers who it may consider for the presentment of offers, which is provided to identity API 18 of service provider 14 for application of provider identifiers, shown in Fig. 1 as 18b. The resulting identifier- enhanced suppression list 30 is applied to bureau data 24. FinServ 12 first runs a query against the credit bureau data set 24 to determine the aggregated population counts within the data set through a query process within the first data clean room 20. From this information, the FinServ 12 selects the final desired records using the identifiers from the service provider's identity graph to key the data, and creates a Pll-based bureau data table of its own, PH bureau data 32.

[0033] Using PH bureau data 32 and cross-reference table 26, the identity resolution service of the service provider 14 can now share the corresponding credit bureau identifiers with the Bureau 16 at share processing 36. In this way, the Bureau 16 is informed of the pre-approved consumers for whom an offer of presentment will be made by the FinServ 12. The Bureau 16 then exports the list of credit bureau identifiers as a "net-down" table 34, in order to post to itscredit posting process. A net-down table is a financial tool used in media buying to calculate the actual cost of messaging placements after applying various discounts, fees, and adjustments. It provides transparency and clarity in the billing process, and includes the gross cost (initial price), various discounts (such as volume discounts or early payment discounts), agency commissions, and any additional fees or charges.

[0034] The activation portion of the process may now be described in more detail. This is the process in which pre-screened offers are made available for presentment out of the second data clean room 22 environment by a digital offer presentment service. A problem that must be overcome is conversion from the identifiers of the service provider's identity graph to online identifiers used by presentment partners. First, the PH bureau data 32 table is subjected to a conversion process so that the identifiers from the identity graph are substituted for equivalent identifiers in an online identifier system at conversion service 38. One such offline system is the AbiliTec® system and an online system is the RampID® identifiers as discussed above, both provided by LiveRamp, Inc. The result is an online identifier table 40.

[0035] The FinServ 12 can then use the online identifier table 40 to make matches to one or more presentment partners within the second data clean room 22. This matching is performed against a presentment partner table 42, which receives measurement data 50 from the publisher concerning site visits, message exposure, and the like. For the matches retrieved, a match query set is exported into an activation table 44. This table contains the online identifiers for those consumers to whom an offer will be made.

[0036] Next, the FinServ 12 runs the overlap on the online identifiers to activation table 44 to create offline activation Pll table 46. Once done, the system can pull the identifiers for these consumers that are used in the identity graph. With the corresponding identifiers from the identity graph, the corresponding Pll for these consumers may be pulled from the identity graph in order to have the contact information necessary in order to present an offer from offline marketing list 48 at publisher 10 through presentment 52.

[0037] In certain embodiments, the invention offers a number of technological improvements over existing systems. First, there is a reduction in overall processing time. By streamlining data processing and query execution within the data clean rooms, the overall computational workload is reduced. This results in faster query responses and decreased processing times, ultimately optimizing compute resources.

[0038] Another advantage of the invention, in certain embodiments, is improved resource utilization. The automated application of identifiers and data protection measures within the clean room environments minimizes the need for manual intervention and redundant computations. This leads to more efficient utilization of compute resources, as tasks are performed accurately and with fewer repetitions, as more fully explained and quantified below.

[0039] Another advantage of the invention, in certain embodiments, is scalability. The architecture described, particularly if it involves a cloud-based infrastructure, offers scalability advantages. As the volume of data and user queries increases, the compute environment will dynamically scale to accommodate the growing demand, ensuring optimal performance and responsiveness.

[0040] Another advantage of the invention, in certain embodiments, is data security measures. The implementation of data protection measures, such as thresholds and hidden columns, will require additional computational overhead for encryption, decryption, and access control. While this may marginally increase the compute workload, it significantly enhances data security and compliance, which outweighs any associated performance costs. This also reduces replication of consumer Pll and regulated credit data, which thereby reduces the risk of such information being exposed due to a hacking attack or other security breach.

[0041] In summary, while the described implementation may introduce some computational overhead due to enhanced security measures and data management processes, it has a net overall significant positive impact on compute environments by improving efficiency, resource utilization, scalability and reducing data latency.

[0042] A particular illustration of process improvement and compute efficiency may be illustrated by comparing a prior art process to a process according to an embodiment of the invention. In a particular prior art example, there are three credit bureau master files, ranging in volume from 1 million to 200 million records. A total of 29 copies of the master files are created in this prior art process, requiring extensive additional processing and data communications to support all of the required file copying. This copying is required to move the files from location to location, staging for transfers, performance of file hygiene, etc. There are a total of 12 file transfers required as well, which places a strain on networks used in the system. In a typical real-world example, 200 million record files are typically broken into 20 to 25 files for transfer, plus additional internal file copies, to facilitate processing, which further exacerbates the transfer load created by this process. In addition, the opt-out process to honor previousopt-outs made by consumers is handled separately from the main file transfer process, and is generally re-run weekly. It is also typical to run a disaster check process, generally at least once before a completed result is shipped. Finally, there are typically at least two hundred audits, including all of the necessary SQL calls to read data required for auditing, which further exacerbates the computing load represented by this prior art approach. A total timeline to complete this entire process, in a typical real-world example, is four to six weeks. As a result, offers often cannot be made in a timely manner because the data used in developing the offer may be out of date by the time the offer is actually presented.

[0043] In contrast to this prior art process, the computing load is greatly diminished in an embodiment of the invention as illustrated. To perform operations on the same data with the same three credit bureau masters, there are only four file copies that must be made, representing an approximately 85% reduction in file copying. This is because the agent of the bureau copying is eliminated since there is no agent of the bureau, and instead the processing all takes place within the data clean rooms. There are no file transfers required at all, in contrast to the 12 transfers required in the prior art approach. The opt-out process is integrated into the data clean room processing, so there is no separate opt-out process (and thus no separate opt-out file copying). Likewise, the separate disaster check process is eliminated. In addition, the audits can be greatly reduced, in a real-world example to around a 90% reduction. And the time to deliver becomes essentially as desired, since the system may be "always on" with no data latency. It could be, for example, triggered for a daily run, in which case the most recent data is always available for purposes of triggering publication of the offers so that offers are delivered in a timely manner, when data is still relevant and accurate.

[0044] Two possible classes of implementations of the invention are referred to herein as a "marketplace" offering (wherein the offers are to be presented across multiple publishers), as well as a "direct" offering (wherein the offers are to be presented through a particular publisher). In the case of a marketplace offering, the process begins with the publisher loading authenticated / certified inventory through the provider marketplace, using the provider's internal identifier. The client can then run / view an overlap of audiences within the data clean room. The audience can then be "activated" (launched) by the client on the marketplace within the data clean room. The activation instructions then pass to the publishers' servers from the provider marketplace.

[0045] Once the activation takes place at the publisher, a consumer may make a login request to the publisher media through an electronic device. After login, the consumer identity is known, and the pre-screened authenticated / certified offer may be presented to the consumer through the consumer's electronic device. The media publisher records the offer "impression" date and time as a timestamp. The timestamp is then sent back to the provider marketplace to note that the authenticated / certified offer was made to the consumer.

[0046] At any subsequent time, the client may request impression certifications back to the marketplace within the activation data clean room. The marketplace then runs the overlap of activated audiences against impression certification logs across all of the publishers, and returns impression certifications across all of these publishers to the client financial institution.

[0047] Because all of the marketplace processing takes place through the data clean room, privacy of the individual consumers involved is protected, while at the same time the client is able to understand the aggregated effectiveness of the authenticated / certified offers that have been made without receiving any personally identifiable information. The use of the data clean room eliminates the requirement in prior systems of an "agent of the bureau" system to relay information between the FinServ and the publishers.

[0048] The direct offering process to a particular publisher is similar to the marketplace process just described, except that interactions with the marketplace are replaced by interactions with the provider's direct activation system, thereby allowing direct interaction with a particular publisher. This process begins with the publisher loading authenticated / certified inventory through the provider direct activation system using the provider's internal identifier. The FinServ can then run / view overlap of audiences for this particular publisher within the activation data clean room. The client then activates this audience using the provider's direct activation system. Next, the activation instruction passes to the particular publisher server from the provider's direct activation system.

[0049] At any point thereafter, the consumer may make a login request to the publisher media for this particular publisher through the consumer's electronic device, and then the offer may be presented to the consumer. As in the marketplace offering example, the particular media publisher records the offer "impression" date and time, and the timestamp is sent back to the provider's direct activation system. At any later time, the FinServ may request impression certifications back to the direct activation system within the data clean room. The overlap of activated audiences against impression certification logs is run for this particular publisher, andthe direct activation system returns impression certifications for this publisher to the FinServ. Again, privacy is protected because the FinServ is not exposed to any personally identifiable information of the relevant consumers.

[0050] The methods described herein may in various embodiments be implemented by any combination of hardware and software. For example, in one embodiment, the methods may be implemented by a computer system or a collection of computer systems, each of which includes one or more hardware processors executing program instructions stored on a computer- readable physical storage medium coupled to the hardware processors. The program instructions may implement the functionality described herein (e.g., the functionality of various hardware servers and other components that implement the network-based cloud and noncloud computing resources described herein). The various methods as illustrated in the figures and described herein represent example implementations. The order of any method may be changed, and various elements may be added, modified, or omitted.

[0051] Fig. 2 is a block diagram illustrating an example computer hardware system, according to various embodiments. Computer system 140 may implement a hardware portion of a cloud computing system as forming parts of the various implementations of the present invention. Computer system 140 may be any of various types of hardware devices, including, but not limited to, a commodity server, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, handheld computer, workstation, network computer, a consumer device, application server, physical storage device, telephone, mobile telephone, or in general any type of computing node, compute node, compute device, and / or hardware computing device.

[0052] Computer system 140 includes one or more hardware processors 140a, 141b... Mln (any of which may include multiple processing cores, which may be single or multi-threaded) coupled to a physical system memory 142 via an input / output (I / O) interface 144. Computer system 140 further may include a network interface 146 coupled to I / O interface 144. In various embodiments, computer system 140 may be a single processor system including one hardware processor 141a, or a multiprocessor system including multiple hardware processors 141a, 141b... Mln. Processors 141a, etc. may be any suitable processors capable of executing computing instructions. For example, in various embodiments, processors 141a, etc. may be general-purpose or embedded processors implementing any of a variety of instruction set architectures.

[0053] In multiprocessor systems, each of processors 141a, etc. may commonly, but not necessarily, implement the same instruction set. The computer system 140 also includes one or more hardware network communication devices (e.g., network interface 146) for communicating with other systems and / or components over a communications network, such as a local area network, wide area network, or the Internet. For example, a client application executing on system 140 may use network interface 146 to communicate with a server application executing on a single hardware server or on a cluster of hardware servers that implement one or more of the components of the systems described herein in a cloud computing environment as implemented in various sub-systems. In another example, an instance of a server application executing on computer system 140 may use network interface 146 to communicate with other instances of an application that may be implemented on other computer systems.

[0054] In the illustrated embodiment, computer system 140 also includes one or more physical persistent storage devices 148 and / or one or more I / O devices 150. In various embodiments, persistent storage devices 148 may correspond to disk drives, tape drives, solid-state memory or drives, other mass storage devices, or any other persistent storage devices. Computer system 140 (or a distributed application or operating system operating thereon) may store instructions and / or data in persistent storage devices 148, as desired, and may retrieve the stored instructions and / or data as needed. For example, in some embodiments, computer system 140 may implement one or more nodes of a control plane or control system, and persistent storage 148 may include the solid-state drives (SSDs) attached to that server node. Multiple computer systems 140 may share the same persistent storage devices 148 or may share a pool of persistent storage devices, with the devices in the pool representing the same or different storage technologies, including such technologies as described above.

[0055] Computer system 140 includes one or more physical system memories 142 that may store code / instructions 143 and data 145 accessible by processor(s) 141a, etc. The system memories 142 may include multiple levels of memory and memory caches in a system designed to swap information in memories based on access speed, for example. The interleaving and swapping may extend to persistent storage devices 148 in a virtual memory implementation, where memory space is mapped onto the persistent storage devices 148. The technologies used to implement the system memories 142 may include, by way of example, static randomaccess memory (RAM), dynamic RAM, read-only memory (ROM), non-volatile memory, solid-state memory, or flash-type memory. As with persistent storage devices 148, multiple computer systems 140 may share the same system memory systems 142 or may share a pool of system memories 142. System memory or memory systems 142 may contain program instructions 143 that are executable by processor(s) 141a, etc. to implement the routines described herein.

[0056] In various embodiments, program instructions 143 may be encoded in binary, Assembly language, any interpreted language such as Java, compiled languages such as C / C++, or in any combination thereof; the particular languages given here are only examples. In some embodiments, program instructions 143 may implement multiple separate clients, server nodes, and / or other components.

[0057] In some implementations, program instructions 143 may include instructions executable to implement an operating system (not shown), which may be any of various operating systems, such as UNIX, LINUX, Solaris™, MacOS™, or Microsoft Windows™. Any or all of program instructions 143 may be provided as a computer program product, or software, that may include a non-transitory computer-readable storage medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to various implementations.

[0058] A non-transitory computer-readable storage medium may include any mechanism for storing information in a form (e.g., software or processing application) readable by a machine (e.g., a physical computer). Generally speaking, a non-transitory computer-accessible medium may include computer-readable storage media or memory media such as magnetic or optical media, e.g., disk or DVD / CD-ROM, coupled to or in communication with computer system 140 via I / O interface 144. A non-transitory computer-readable storage medium may also include any volatile or non-volatile media such as RAM or ROM that may be included in some embodiments of computer system 140 as system memory 142 or another type of memory. In other implementations, program instructions may be communicated using optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.) conveyed via a communication medium such as a network and / or a wired or wireless link, such as may be implemented via network interface 606. Network interface 146 may be used to interface with other devices 142, which may include other computer systems or any type of external electronic device.

[0059] In some embodiments, system memory 142 may include data store 145, as described herein. In general, system memory 142 and persistent storage 148 may be accessible on other devices 142 through a network and may store data blocks, replicas of data blocks, metadata associated with data blocks, and / or their state, database configuration information, and / or any other information usable in implementing the routines described herein.

[0060] In one embodiment, I / O interface 144 may coordinate I / O traffic between processors 141a, etc., system memory 142, and any peripheral devices in the system, including through network interface 146 or other peripheral interfaces. In some embodiments, I / O interface 144 may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory 142) into a format suitable for use by another component (e.g., processors 141a, etc.). In some embodiments, I / O interface 144 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, as examples. Also, in some embodiments, some or all of the functionality of I / O interface 144, such as an interface to system memory 142, may be incorporated directly into processor(s) 141a, etc.

[0061] Network interface 146 may allow data to be exchanged between computer system 140 and other devices attached to a network, such as other computer systems (which may implement one or more storage system server nodes, primary nodes, read-only node nodes, and / or clients of the database systems described herein), for example. In addition, I / O interface 144 may allow communication between computer system 140 and various I / O devices 150 and / or remote storage 148. Input / output devices 150 may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or retrieving data by one or more computer systems 140. These may connect directly to a particular computer system 140 or generally connect to multiple computer systems 140 in a cloud computing environment, grid computing environment, or other system involving multiple computer systems 140.

[0062] Multiple input / output devices 150 may be present in communication with computer system 140 or may be distributed on various nodes of a distributed system that includes computer system 140. In some embodiments, similar input / output devices may be separate from computer system 140 and may interact with one or more nodes of a distributed systemthat includes computer system 140 through a wired or wireless connection, such as over network interface 146.

[0063] Network interface 146 may commonly support one or more wireless networking protocols (e.g., Wi-Fi / I EEE 802.11, or another wireless networking standard). Network interface 146 may support communication via any suitable wired or wireless general data networks, such as other types of Ethernet networks, for example. Additionally, network interface 146 may support communication via telecommunications / telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and / or protocol. In various embodiments, computer system 140 may include more, fewer, or different components (e.g., displays, video cards, audio cards, peripheral devices, or an Ethernet interface).

[0064] Any of the distributed system embodiments described herein, or any of their components, may be implemented as one or more network-based services in the cloud computing environment. For example, a read-write node and / or read-only nodes within the database tier of a hardware database system may present database services and / or other types of physical data storage services that employ the distributed storage systems described herein to clients as network-based services.

[0065] In some embodiments, a network-based service may be implemented by a software and / or hardware system designed to support interoperable machine-to-machine interaction over a network. A web service may have an interface described in a machine-processable format. Other systems may interact with the network-based service in a manner prescribed by the description of the network-based service's interface. For example, the network-based service may define various operations that other systems may invoke, and may define a particular application programming interface (API) to which other systems may be expected to conform when requesting the various operations.

[0066] In various embodiments, a network-based service may be requested or invoked through the use of a message that includes parameters and / or data associated with the network-based services request. Such a message may be formatted according to a particular markup language such as Extensible Markup Language (XML), and / or may be encapsulated using a protocol. To perform a network-based services request, a network-based services client may assemble a message including the request and convey the message to an addressable endpoint (e.g., aUniform Resource Locator (URL)) corresponding to the web service, using an Internet-based application layer transfer protocol such as Hypertext Transfer Protocol (HTTP).

[0067] Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

[0068] Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of the exemplary methods and materials are described herein. It will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts herein.

[0069] All terms used herein should be interpreted in the broadest possible manner consistent with the context.

[0070] When a grouping is used herein, all individual members of the group and all combinations and sub-combinations possible of the group are intended to be individually included.

[0071] When a range is stated herein, the range is intended to include all sub-ranges within the range, as well as all individual points within the range.

[0072] When "about," "approximately," or like terms are used herein, they are intended to include amounts, measurements, or the like that do not depart significantly from the expressly stated amount, measurement, or the like, such that the stated purpose of the apparatus or process is not lost.

[0073] All references cited herein are hereby incorporated by reference to the extent that there is no inconsistency with the disclosure of this specification.

[0074] The present invention has been described with reference to certain preferred and alternative embodiments that are intended to be exemplary only and not limiting to the full scope of the present invention, as set forth in the appended claims.

Claims

Claims1. A system for the exchange of regulatory-compliant and privacy-compliant consumer credit data, comprising: a credit bureau server; a financial services institution server; a service provider server; a first data clean room communicatively coupled to the credit bureau server, the financial services institution server, and the service provider server, wherein the first data clean room is configured to: connect consumer credit data from the credit bureau server; process the consumer credit data with the service provider server to identify pre-screened consumers for credit offers; and enable the financial services institution server to directly access the processed consumer credit data without intervention of an agent of the bureau; and a second data clean room communicatively coupled to both the financial services institution server and the service provider server, wherein the second data clean room is configured to facilitate presentment of firm offers of credit to the identified prescreened consumers.

2. The system of claim 1, wherein the first data clean room is further configured to apply a pseudonymous identifier to the consumer credit data.

3. The system of claim 2, wherein the pseudonymous identifier is hidden from the financial services institution server.

4. The system of claim 1, wherein the first data clean room is further configured to log all queries made by the financial services institution server.

5. The system of claim 1, wherein the first data clean room is further configured to implement data privacy protection measures including thresholds and hidden columns.

6. The system of claim 1, wherein the first data clean room is further configured to perform automated net-downs on the consumer credit data.

7. The system of claim 1, further comprising a publisher server communicatively coupled to the second data clean room, wherein the publisher server is configured to present the firm offers of credit to consumers.

8. The system of claim 7, wherein the publisher server is further configured to record a timestamp of offer presentment.

9. The system of claim 1, wherein the second data clean room is further configured to provide impression certifications to the financial services institution server without exposing personally identifiable information of consumers.

10. A method for exchange of regulatory-compliant and privacy-compliant consumer credit data, comprising: receiving, at a first data clean room, consumer credit data from a credit bureau server; processing, by the first data clean room, the consumer credit data to identify prescreened consumers for credit offers; enabling a financial services institution server to directly access the processed consumer credit data without intervention of an agent of the bureau; and facilitating near real-time presentment of firm offers of credit to the identified prescreened consumers through a second data clean room.

11. The method of claim 10, further comprising applying a pseudonymous identifier to the consumer credit data.

12. The method of claim 11, wherein the pseudonymous identifier is hidden from the financial services institution server.

13. The method of claim 10, further comprising logging all queries made by the financial services institution server.

14. The method of claim 10, further comprising implementing data privacy protection measures including thresholds and hidden columns.

15. The method of claim 10, further comprising performing automated net-downs on the consumer credit data.

16. The method of claim 10, further comprising: receiving, at a publisher server, activation instructions for presenting firm offers of credit; andpresenting, by the publisher server, the firm offers of credit to consumers based on the activation instructions.

17. The method of claim 16, further comprising: recording, by the publisher server, a timestamp of offer presentment; and communicating the timestamp through the second data clean room.

18. The method of claim 10, further comprising providing impression certifications to the financial services institution server without exposing personally identifiable information of consumers.

19. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform a method for exchange of regulatory-compliant and privacy-compliant consumer credit data, the method comprising: receiving consumer credit data from a credit bureau server; processing the consumer credit data to identify pre-screened consumers for credit offers; enabling a financial services institution server to directly access the processed consumer credit data without intervention of an agent of the bureau; and facilitating near real-time presentment of firm offers of credit to the identified prescreened consumers.

20. The non-transitory computer-readable storage medium of claim 19, wherein the method further comprises: applying a pseudonymous identifier to the consumer credit data; logging all queries made by the financial services institution server; implementing data privacy protection measures including thresholds and hidden columns; and providing impression certifications to the financial services institution server without exposing personally identifiable information of consumers.

Images